Google Drive
Gist
Clipboard
Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
(Meeting attendees, feel free to add items here!)
https://github.com/rust-lang/surveys/pull/243
TC: @scottmcm proposed that we discuss the questions to be asked on the Rust Survey, particularly about the features that people may want added to the language.
pnkfelix: These are phrased as lists of features, but maybe it would be better to phrase it as problems areas to solve.
TC: The challenge with problem areas is that people tend to want all problems solved.
tmandry: Maybe we could ask people to do a ranking.
pnkfelix: There's a difference between features that affect the API that people can provide from features that let people write the kind of code they want to write.
eholk: Looking at the list of features, would people even know what things like higher-kinded types are? Maybe we should say what kind of code features like that would let you write.
TC: There's tension between that and the compression needed for a survey. Macroexpanding each feature would probably make the length untenable. Also, if a lot of people see "HKT" and say, "yes, I want that", the fact that those people even know about it provides non-zero information.
tmandry: We should ask a survey expert.
scottmcm: Thinking out loud:
Which of these is causing you the most trouble these days?:
const fnscottmcm: What's the timeline here?
tmandry: It usually happens in the fall.
Lokathor: We could discuss on Zulip.
Consensus: Let's discuss on Zulip.
Link: https://github.com/rust-lang/rust/pull/115476
TC: RalfJ is asking for us to remove a concern that was filed to check that T-opsem had looked at this. They have now.
pnkfelix: I'll resolve the concern.
Concensus: We'll resolve the concern and this will go into FCP.
Link: https://github.com/rust-lang/rust/pull/115524
TC: This is in FCP. Any objections to unnominating?
Consensus: Let's unnominate.
Link: https://github.com/rust-lang/rust/pull/116015
TC: This is in FCP. Any objections to unnominating?
Consensus: Let's unnominate.
gen keyword for gen {} blocks and gen fn in 2024 edition" rust#116447Link: https://github.com/rust-lang/rust/pull/116447
TC: @oli raised this issue:
gen fn foo() {}already did not parse on any edition, so I just added a custom (slightly incorrect) error message for it, when the 2024 edition is enabled.
gen {}blocks are technically able to exist, as someone could name a structgenand then try to initialize its fields. With this PR this will be forbidden in 2024. I could start linting it on older editions.Historically (async blocks,
dyntraits) we've first linted on one edition, then errored in the follow up edition. That would be to lint in 2024 and hard error in 2027. I guess we could go withk#genfor 2024 edition.Generators tracking issue #43122
The semantics of gen blocks and
gen fnare deliberately omitted from this PR. While I have opinions on those, development on them should follow the usual T-lang path for new featuresr? lang
TC: @scottmcm nominated:
Note that since rust-lang/rfcs#2441 (comment) lang has said that we're not pre-reserving keywords for features that haven't been RFC'd.
Thus the default expectation here is that this will be written using the syntax space reserved in https://rust-lang.github.io/rfcs/3101-reserved_prefixes.html for now, and keyword reservations will happen along with the semantic RFC.
I think that
gen fncould probably happen without that, though, by havinggenthere be a contextual keyword. But in expressions, it would bek#gen { ... }(ordo gen { ... }or whatever) for now, even in a future edition.(Nominated for lang meeting discussion regardless.)
eholk: Do we want to RFC this before 2024?
pnkfelix: There is an RFC linked from the issue.
https://github.com/rust-lang/rfcs/pull/2033
(Discussion that it being an experimental RFC is good enough for reserving a keyword.)
Lokathor: Perhaps we should do a quick RFC to reserve the keyword based on the earlier RFC. Then we're policy compliant.
tmandry: Is that the policy?
scottmcm: I notice the RFC doesn't contain generator blocks.
Lokathor: Right.
tmandry: It needs an RFC, but it could be a small one.
eholk: Do we think that gen is a common variable name?
scottmcm: But the RFC can deal with that.
pnkfelix: We shouldn't block the experiment on the RFC.
scottmcm: The experiment should move forward with k#gen.
pnkfelix: I'm concerned about the semantics holding up getting the keyword into 2024.
scottmcm: The RFC about not reserving covered this case, e.g. not repeating the experience of throw.
eholk: This seems distinguishable. We're much closer here.
tmandry: I'm in favor of reserving the keyword on the basis of the fact that this is a feature that we want.
TC: What if we proposed an RFC that says that we're going to write a later RFC to pin down the semantics (on the basis of the experiment being run), but we're going to reserve the keyword now.
scottmcm: It sounds though, based on what eholk said, that we may have the semantics somewhat pinned down based on the async/await work.
eholk: That's true, but there are some open questions.
scottmcm: Maybe the RFC should say the semantics we know now, and leave open the questions that are open.
TC: Who has the most context on this?
eholk: Myself and tmandry.
tmandry: And we should ask @oli.
scottmcm: I'll write a comment on the thread.
Consensus: We'll try to find someone to write an RFC for this, and we'll leave a comment on the issue that we're looking for one.
Link: https://github.com/rust-lang/rust/issues/116557
TC: nikomatsakis nominated this:
We had some discussion about types/lang team interaction. We concluded a few things:
- Pinging the team like @rust-lang/lang is not an effective way to get attention. Nomination is the only official way to get attention.
- It's ok to nominate things in an "advisory" capacity but not block (e.g., landing a PR), particularly as most any action can ultimately be reversed. But right now, triagebot doesn't track closed issues, so that's a bit risky.
Action items:
- We should fix triagebot to track closed issues.
Consensus: Let's discuss this when nikomatsakis is available.
anonymous_lifetime_in_impl_trait" rust#107378Link: https://github.com/rust-lang/rust/pull/107378
TC: This had been waiting on the author to answer some questions. Those have now been answered, and tmandry nominated this for further discussion.
tmandry: The answer to our questions on whether the lifetime should be higher-ranked is that we had accidentally stabilized this with async fn.
pnkfelix: If we think this is wrong, we shouldn't expand the amount of code affected.
tmandry: I'm not obvious what the correct behavior is. Maybe we want to have Niko to discuss.
scottmcm: I agree with tmandry that associated types are outputs https://github.com/rust-lang/rfcs/pull/2548, whereas Self and generics are inputs.
TC: We could ask for a document that does a de novo analysis. I.e., setting aside the accidental stabilization, we should have a write-up about the pros and cons for each choice.
tmandry: I'll leave some thoughts on the PR.
Consensus: We should think further about this and discuss with nikomatsakis. We'll ask for more analysis on the PR.
Link: https://github.com/rust-lang/rust/pull/115333
TC: @tmandry nominated this:
I'll proxy @the8472's concern, to make sure we come to a resolution before merging. I'm also re-nominating for lang team discussion so the team has a chance to flag any concerns they have with this change.
Since the change would be more conservative than the original proposal, though, I don't think it requires a new FCP.
@rfcbot concern None-value of
Option<fat-reference>@rustbot label I-lang-nominated
tmandry: I wanted people to be aware here. We don't need to redo the FCP since we're making it more conservative.
scottmcm: +1. Since we don't guarantee the representation of fat pointers in general, it would be strange to do here.
pnkfelix: +1.
tmandry: I'll leave a note.
Consensus: We'll reduce the PR to the more conservative variant and move forward with the proposed FCP.
Link: https://github.com/rust-lang/rust/pull/116284
TC: In the 2023-10-03 meeting, we discussed and decided to ask Ralf what he thinks we should do. Ralf replied:
First, what is the motivation to eliminate NaN specifically?
NaN is by far the least well-behaved class of float values when it comes to comparison, since they don't even satisfy reflexivity. No matter the mental model for
match, it seems very hard to justify a value not even matching itself.Second, do we have a sense for the overall "plan" around the semantics of pattern matching and floating point values? At some point we expected to remove that, but now it seems like we are allowing floats, presumably with today's semantics, is that correct?
There was the plan to disallow floats entirely as part of the move to enforcing structural matching (this even got RFC'd). Then t-lang rejected #84045, which is a departure from that plan. If t-lang has a long-term plan here than you didn't tell us about it. :)
TC: There is some further discussion on the issue.
tmandry: We can unnominate; we have a design meeting next week on this.
Consensus: We'll discuss tomorrow.
Link: https://github.com/rust-lang/rust/pull/116098
TC: RalfJ raised this issue:
In #84045 the lang team rejected making this a hard error. So clearly we shouldn't have a lint saying "this will be a hard error in the future".
Fixes #41620
pnkfelix: Want to discuss this at the design meeting?
all: +1.
Consensus: We'll discuss this at the design meeting next week.
Link: https://github.com/rust-lang/rust/issues/114582
TC: We discussed this on 2023-08-15.
@RalfJ points out that certain compiler intrinsics don't fit within the memory model of the Rust Abstract Machine. For this one in particular, in the time between doing a non-temporal store and before doing a store fence, things are a bit nuts. But this has a performance benefit as it bypasses the cache, so "fixing" it by eliminating the performance benefit isn't a good option. The meeting consensus was to table this while looking for ways to raise awareness. As @scottmcm said, "it wouldn't be the first thing you could do in unsafe that turns out to be sketchy."
TC: Some discussion followed about this issue after the meeting.
TC: Is there anything we want to do before unnominating this?
Lokathor: Ralf wants us to deprecate or mark as permanently unsound these intrinsics.
tmandry: That would seem a disappointing outcome. These are probably useful.
Lokathor: One problem is that you want to use these inside a loop, and you'd get bad codegen if you used assembly.
tmandry: It seems like we need some way to express this.
Lokathor: Ralf's position is that these don't fit in the Rust abstract machine, and that if you're using these, you're not writing Rust code.
TC: There is the option to extend the Rust memory model to allow expressing these. That's a big ask, of course.
tmandry: Perhaps we should lint/warn on their use. We could use the deprecation machinery.
Lokathor: The fastest path in terms of existing infrastructure is deprecating them.
tmandry: I'll write a comment that we should lint on this. We can discuss if there's a response next time. Otherwise, let's unnominate.
pnkfelix: A lint is a step. It needs serious investigation. Jubilee has been adding the SFENCE to people's code across GitHub.
TC: That's a great point. We need to suggest to people to add the SFENCE in the lint.
Consensus: We'll propose a lint for this, and we'll discuss it again.
(The meeting ended here.)
.await does not perform autoref or autoderef" rust#111546Link: https://github.com/rust-lang/rust/issues/111546
TC: This was nominated for T-lang (and for T-types) by WG-async. @tmandry said:
We discussed this in a recent wg-async meeting (notes). The consensus was that we thought the change was well-motivated. At the same time, we want to be cautious about introducing problems (namely backwards compatibility).
There should probably be a crater run of this change, and we should also work through any problematic interactions that could be caused by this change. (@rust-lang/types should probably weigh in.)
The main motivation for the change is the analogy to
.method(), as well as to wanting async and sync to feel similarly convenient in most cases.Note that there is another analogy that works against this, the analogy to
IntoIterator, where the lang-effect form (for _ in foo {}) does not do autoref/autoderef. However, given that this looks very different fromfoo.await, and taking a reference with that form is significantly more convenient (for x in &fooorfor x in foo.iter()vs(&foo).await), it seemed the analogy was stretched pretty thin. So we elected to put more weight on the above two considerations.That being said, this change would need lang team signoff. You can consider this comment wg-async's official recommendation to the lang team.
Link: https://github.com/rust-lang/rfcs/pull/3498
TC: FCP merge has been proposed. Some minor edits are in progress, but no serious concerns are outstanding.
Link: https://github.com/rust-lang/rfcs/pull/3503
TC: The following syntax is being proposed for addition to Rust:
#!/usr/bin/env cargo
```cargo
[dependencies]
clap = { version = "4.2", features = ["derive"] }
```
use clap::Parser;
PartialOrd and Ord for Discriminant" rust#106418Link: https://github.com/rust-lang/rust/pull/106418
TC: We discussed in the 2023-09-26 meeting. We decided to simply let T-libs-api know about what we had discussed. Niko left a comment to the effect that "right now we seem to have no good options."
TC: There has since been further discussion on the issue.
Link: https://github.com/rust-lang/rust/issues/106447
TC: The FCP to close this issue has been completed. However, @Amanieu is still looking for a way forward. There's been some discussion on Zulip about this.
TC: We discussed this in the 2023-09-26 triage meeting without a full resolution, but decided that adding ptr::addr_eq may be one small step forward. @pnkfelix proposed this in the ticket and then to T-libs-api. @dtolnay seconded the request and asked for a PR.
Link: https://github.com/rust-lang/rust/issues/113527
TC: We've created a new Zulip stream for this work.
TC: A job description for the editor has been discussed. There seems to be consensus to move forward on the hiring process.
TC: There is outstanding discussion on the appropriate name of this document.
TC: There is an outstanding discussion ongoing about the goals of the specification.
TC: Niko has proposed to create the team, with pnkfelix and Mara as the leads, and for that team to work to draft a new set of requirements.
static mut [Edition Idea]" rust#114447Link: https://github.com/rust-lang/rust/issues/114447
TC: We discussed on 2023-09-05 and the consensus was in favor of going in this direction. We left a comment with the path forward and labeled it E-help-wanted.
TC: Are there any particular people we might want to ping who we know might have an interest in this?
async fn and return-position impl Trait in trait" rust#115822Link: https://github.com/rust-lang/rust/pull/115822
TC: This is in FCP.
Link: https://github.com/rust-lang/rfcs/pull/3336
TC: We discussed this in an RFC read on 2023-09-27. @scottmcm said that he would propose FCP merge.
Link: https://github.com/rust-lang/rfcs/pull/3437
TC: This RFC has also been proposed for a design meeting as an RFC read, but it has not yet been scheduled for one.
TC: We discussed this in the 2023-09-26 triage meeting. We decided that this needed more discussion and that we'd leave a comment about what was discussed in the issue. Niko has posted that comment.
Link: https://github.com/rust-lang/rust/pull/112879
TC: We're waiting on @oli to investigate an unexpected incremental build-time regression. I made sure that @oli knows that, and knows that we resolved the fundamental question that was blocking this earlier in RFC 3477.
warnings level for a specific lint via command line" rust#113307Link: https://github.com/rust-lang/rust/pull/113307
TC: We discussed in the 2023-09-26 meeting, but were unsure of the question we were being asked. We've reiterated on the issue a request for clarification.
None.
Link: https://github.com/rust-lang/lang-team/pull/216
Link: https://github.com/rust-lang/lang-team/pull/225
Link: https://github.com/rust-lang/rfcs/pull/3349
f16 and f128 float types" rfcs#3453Link: https://github.com/rust-lang/rfcs/pull/3453
S-waiting-on-teamLink: https://github.com/rust-lang/rust/issues/65991
anonymous_lifetime_in_impl_trait" rust#107378Link: https://github.com/rust-lang/rust/pull/107378
Link: https://github.com/rust-lang/rust/pull/115476
Link: https://github.com/rust-lang/rust/pull/115524
async fn and return-position impl Trait in trait" rust#115822Link: https://github.com/rust-lang/rust/pull/115822
Link: https://github.com/rust-lang/rust/pull/116098
Check your boxes!
Link: https://github.com/rust-lang/rfcs/pull/2375
Link: https://github.com/rust-lang/rfcs/pull/3325
Link: https://github.com/rust-lang/rfcs/pull/3498
Link: https://github.com/rust-lang/rust/issues/65991
mem::discriminant" rust#69821Link: https://github.com/rust-lang/rust/issues/69821
Link: https://github.com/rust-lang/rust/pull/104087
anonymous_lifetime_in_impl_trait" rust#107378Link: https://github.com/rust-lang/rust/pull/107378
Link: https://github.com/rust-lang/rust/issues/107645
Link: https://github.com/rust-lang/rust/pull/112879
Link: https://github.com/rust-lang/rust/issues/114986
c_unwind full stabilization request: change in extern "C" behavior" rust#115285Link: https://github.com/rust-lang/rust/issues/115285
Link: https://github.com/rust-lang/rust/pull/115333
Link: https://github.com/rust-lang/rust/pull/115476
#[expect] attribute" rust#115980Link: https://github.com/rust-lang/rust/issues/115980
const_maybe_uninit_zeroed and const_mem_zeroed" rust#116218Link: https://github.com/rust-lang/rust/pull/116218
Link: https://github.com/rust-lang/rust/pull/116485
Link: https://github.com/rust-lang/rust/pull/115524
async fn and return-position impl Trait in trait" rust#115822Link: https://github.com/rust-lang/rust/pull/115822
Link: https://github.com/rust-lang/rust/pull/116015
None.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe