Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
(Meeting attendees, feel free to add items here!)
Josh: We should unblock the spec subteam process.
Josh: We need to get to a concrete PR with a concrete team. T-lang needs to come to a consensus on who should be on the team and what if anything needs to happen before the work of the team can start.
(Discussion about which teams manage their own membership. Should this team manage its own membership?)
Josh: There's an expectation that at least one person from t-lang will be on the team. I cannot imagine a scenario where t-lang would want to add someone against the wishes of the team. But would the team want to add someone that t-lang wouldn't want?
Josh: Seems fine to me for the team to manage it itself.
pnkfelix: Agreed, but lang should have some influence on it. It all makes sense as long as there is a T-lang member on the team.
Josh: Do we have consensus?
pnkfelix, tmandry: no objection
tmandry: Larger question. This is a subteam of lang. There's an open question as to the initial scope of the spec.
Josh: Initial scope is language. The result of their work will be approved by several teams before it will be considered a spec.
pnkfelix: Initial team will be myself, Mara, Eric, at least. So we'll have good representation.
Josh: That initial group was the group for doing the interviews.
pnkfelix: We can table the issue of t-lang influence over membership until and unless t-lang doesn't have representation on that team.
Lokathor: The doc still has to be approved by t-lang, so maybe it's not a big deal if a t-lang member is absent for awhile.
TC: It is a subteam of t-lang after all. At the end of the day, t-lang has authority here.
tmandry: Maybe we should just state that there should always be a lang team member.
Consensus:
pnkfelix: There was discussion in the t-opsem meeting about documentation on this issue. We can discuss this on Zulip. Lokathor, do you remember more details about this?
TC: If it doesn't get enough discussion on Zulip, we can add it to the agenda for next week.
pnkfelix/all: Sounds good.
None.
None.
None.
S-waiting-on-teamLink: https://github.com/rust-lang/rust/issues/65991
TC: Meeting consensus last week was that this was waiting on @nikomatsakis.
TC: Four days ago, @nikomatsakis resolved his concern:
Based on what we see in #112355, I feel comfortable moving forward now (and potentially doing follow up work later).
pnkfelix: Interestingly, a paper was published that touched on this very issue:
"Tighten Rust’s Belt: Shrinking Embedded Rust Binaries"
https://sing.stanford.edu/site/publications/rust-lctes22.pdf
pnkfelix: The paper shouldn't be blocking; it's the same thing we discussed previously that we could add later about a flag on the trait or a compiler flag.
tmandry: Would that latter one be a compiler flag that changes language behavior?
pnkfelix: It's really just turning off a feature.
Josh: It's still a hazard. It requires coordination; you couldn't reliably use it then. If we want to offer an opt-in or opt-out, it should be on the type or the crate level.
pnkfelix: But do we see it as a blocking concern for this feature?
Josh: As an opt-out, no. It's not a one-way door for the purposes of an opt-out. It's only a one-way door for an opt-in.
tmandry: But it would be a breaking change for a crate's API to later add an opt-out. The most conservative thing to do is to add the opt-out first.
Josh: The most conservative thing is to not turn it on until a new edition.
Lokathor: But if it's edition-based, then isn't switching editions a problem…?
tmandry: Maybe the edition conversion tool could add it everywhere. It'd be noisy.
TC: We had discussed in earlier weeks that maybe we don't really care that this is a trivial breakage. Have we changed our minds there?
pnkfelix: I'm in that camp that it's trivial and OK.
tmandry: Since we're paying the cost already. I think I'm fine with it. It does feel like something where I'd like commentary from the community. We don't really have a way to measure the impact.
tmandry: Looking at #112355, I'm left with the impression that we're measuring the wrong thing.
tmandry: It makes me nervous. But I won't block it if everyone else wants to move forward. I'd feel better if there were a way to measure the impact.
Josh: I don't find myself with a strong opinion one-way or the other. I don't feel like we need more data. It's not per trait object, it's per trait impl. So it doesn't seem like a massive impact for most people. So I'm fine adding an opt-out later.
Josh: Plus we could probably get the compiler to optimize it further. So I'm not concerned about the cost, and I'm usually the one concerned about the cost.
pnkfelix: If we are going to explore ways to opt-in or opt-out, it'd be good to also look at the case of Box<dyn ...>, so I don't see a case to block here.
tmandry: I don't have an understanding of what the cost estimate is. Josh, what's your understanding of it?
Josh: It's a constant factor times the number of trait impls you have, it's not proportional to the number of trait objects you have at runtime.
TC: We're already paying that cost also, so people would already notice this impact.
tmandry: People do scream about Rust binary size though.
Lokathor: But it's not saving much to delete these vtables?
pnkfelix: The paper discussed 12 bytes per vtable.
Josh: I'm in favor of finding a way to teach the compiler to do optimization after-the-fact. If anyone writes dyn Iterator, they'll get a terrifying size, but that isn't a blocker.
tmandry: I'm concerned about this, but I'm willing to move forward because this is a big feature for the language, and the extent of the downside for users is probably minor.
TC: The consensus seems to be to start an FCP.
pnkfelix: I'll start FCP.
unnecessary_send_constraint lint for &(dyn ... + Send)" rust#110961Link: https://github.com/rust-lang/rust/pull/110961
TC: The FCP merge is complete, but this is waiting on the author. Do we want to remove S-waiting-on-team?
Josh: I'll remove the label… done.
Link: https://github.com/rust-lang/rust/pull/113126
TC: The meeting consensus last week was that this is waiting on @nikomatsakis to remove his concern. That concern has not yet been removed, though the author has replied to it.
TC: Consensus this week is that we're still waiting on that.
Check your boxes!
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
- raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
- waiting-on-update-re-using-char-and-string-tables (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1503875165)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
I do think we should permit
br"¥¥¥", but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.I'm going to go ahead and propose FCP for this. This does not preclude making further changes to how this information is presented.
@rfcbot merge
@rfcbot concern raw-byte-strings-with-unicode
TC: This is waiting on the author.
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
@rfcbot merge
TC: The meeting consensus 2023-07-18 was that this was a good idea.
f16 and f128 float types" rfcs#3453Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
- @Amanieu
- @BurntSushi
- @dtolnay
- @joshtriplett
- @m-ou-se
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
Since we define
f32andf64to be IEEEbinary32andbinary64, it seems entirely reasonable to also includebinary16andbinary128as well, working analogously.Let's see what others think:
@rfcbot fcp mergeThough I do expect that this will be non-trivial to stabilize, in terms of implementation effort, like how
u128was easy to RFC but very hard to make work broadly.Compiler folks: Please comment if you think this should be postponed as impractical to implement in the foreseeable future.
(Practically, we might not accept
f128: Display + FromStrfor a while even on nightly, because of size impacts of being able to accurately print/parse such precision, for example.)
TC: @scottmcm proposed to merge this 2023-08-04.
Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
- @cramertj
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
Concerns:
expectations-around-panics-in-inline-constresolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210- optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
post-monomorphization-errorsresolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779- should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
@rfcbot fcp merge
TC: The issue had been marked as blocked on #86730 by Dylan-DPC. We didn't understand that, so we asked. It turns out that was in error; Dylan-DPC has removed the block.
TC: The remaining discussion suggested we may want to move forward:
scottmcm: We may be OK to move forward here; we discussed that we wanted this. Maybe we just need to resolve our concerns.
TC: How are we feeling about this one?
tmandry: This is blocked on #112879.
TC: That's one of the nominated items. Let's jump straight there.
anonymous_lifetime_in_impl_trait" rust#107378Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
- elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
- why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
@rfcbot merge
We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.
TC: This is waiting on the author.
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
- encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
- nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
@rfcbot fcp merge
We held a design meeting yesterday where we reviewed this document prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.
The document proposed the following resolution to this issue:
- The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
- Functions and methods must have the hidden type that they intend to constrain within their signature – within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
- Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
- A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
- The hidden type may be constrained by functions, methods, constants, and statics.
The doc goes into more detail about the justifications and alternatives.
Given all this, I propose to merge and accept this proposal.
TC: This was discussed in a design meeting on 2023-05-31. Subsequently @tmandry raised concerns. We had a mini-design meeting on 2023-06-29 regarding those. A long thread on Zulip followed from that.
TC: TAIT is also separately affected by the capturing of lifetimes discussed in the design meeting on 2023-07-26. That is pending an RFC that I will be submitting (the PR for the implementation is ready).
Or pattern without allocating place" rust#111752Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
Thanks for the summary, @cjgillot !
I think lowering short-circuiting operators as control flow makes good sense, and fits well with future potential for things like let chains or scoping for an
isoperator. This does suggest that if we ever allow overriding them then those overrides ought to work via control-flow as well, but I don't see that as blocking anything that we'd need. (For example, we could still lower the LHS to a call that returns anOption, and have the lowering work on thatOption.)@rfcbot merge
TC: @scottmcm proposed to merge this on 2023-07-18.
TC: There was no discussion in the meeting last week on this.
TC: This week, we discussed this as one of the nominated items.
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
- backwards-incompat (https://github.com/rust-lang/rust/pull/113126#issuecomment-1650355872)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
@rfcbot fcp merge
Awesome! Going to kick off FCP and we can review and discuss.
TC: This one is waiting on @nikomatsakis, as above.
const contexts." rust#113510Link: https://github.com/rust-lang/rust/pull/113510
TC: @scottmcm on 2023-08-03:
(Re-nominated to encourage discussion of the exact text on Tuesday.)
#[repr(Rust)]" rust#114201Link: https://github.com/rust-lang/rust/pull/114201
TC: We discussed this 2023-08-01 and the consensus was that this was easy and a good idea.
Josh: This is now in FCP with three boxes checked.
None.
Link: https://github.com/rust-lang/rfcs/pull/3336
TC: There's been considerable recent discussion of this over on Zulip.
Link: https://github.com/rust-lang/rust/issues/54503
TC: Based on feedback from t-lang, @xFrednet created a list of use-cases and is seeking review from t-lang.
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.
Link: https://github.com/rust-lang/rust/pull/110166
TC: This has completed its FCP merge, but it is waiting on the author for some final changes.
TC: Should we unnominate this?
TC: Josh, what do you think about this?
Josh: No strong feelings here.
TC: Do we have a general policy about keeping or dropping the nomination when we're waiting on the author?
Josh: When we're waiting on the author, we tend to remove the nomination unless we really want to stay on top of it whether the author does or not.
Josh: That doesn't seem the case here. Let's unnominate this… done.
Or pattern without allocating place" rust#111752Link: https://github.com/rust-lang/rust/pull/111752
TC: @scottmcm proposed to merge this on 2023-07-18.
Josh: I'm interested in at least briefly looking at this.
Josh: This proposes to use a mechanism that is more straightforward. The lang nomination is about what doors this closes.
Josh: This is allowing more things in certain constructed test cases. It doesn't disallow any old things.
Josh: This seems harmless since it doesn't affect temporary lifetimes.
tmandry: My understanding is that basically this makes borrowck sensitive to short-circuiting. Is there anything else here?
tmandry: I'm going to check my box and leave a comment to verify my understanding.
TC: With three boxes checked, this is going to move into FCP merge.
Link: https://github.com/rust-lang/rust/issues/112194
TC: We resolved this in the design meeting on 2023-07-26. That is pending an RFC that I will be submitting.
TC: We should probably unnominate this RPITIT issue.
Josh: I'll unnominate… done.
Link: https://github.com/rust-lang/rust/pull/112879
TC: This is a blocker for the stabilization of inline_const. We discussed this recently and decided we were OK with it. @tmandry posted a comment on 2023-07-19 asking about a possible crater run. Nothing has moved here since.
tmandry: This is blocking inline_const.
TC: Is your comment in this issue blocking or is it informational?
tmandry: It's not exactly blocking. Should we FCP this?
Lokathor: We usually do an FCP when possible and people can raise concerns if appropriate.
tmandry: This one is also labeled t-compiler. Part of me wants to remove t-compiler.
TC: I propose we remove t-compiler and do the t-lang FCP separately. That will give a clearer indication to t-compiler, and then they can proceed as they think best.
tmandry: Doing that now.
Link: https://github.com/rust-lang/rust/pull/113126
TC: This one is waiting on @nikomatsakis, as above.
warnings level for a specific lint via command line" rust#113307Link: https://github.com/rust-lang/rust/pull/113307
TC: This is in a t-compiler proposed FCP, but @jieyouxu has a specific question for t-lang.
TC: We discussed this in the meeting on 2023-07-25 without resolution.
const contexts." rust#113510Link: https://github.com/rust-lang/rust/pull/113510
TC: @scottmcm on 2023-08-03:
(Re-nominated to encourage discussion of the exact text on Tuesday.)
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: We discussed various ways of unblocking this work as a separate agenda item.
Link: https://github.com/rust-lang/rust/pull/113586
TC: The FCP merge has completed. This should probably be merged and unnominated.
Josh: Going to merge and unnominate… done.
#[repr(Rust)]" rust#114201Link: https://github.com/rust-lang/rust/pull/114201
TC: We discussed this 2023-08-01 and the consensus was that this was easy and a good idea.
Josh: We should unnominate. Without objections, unnominating… done.
static mut [Edition Idea]" rust#114447Link: https://github.com/rust-lang/rust/issues/114447
On 2023-08-04, @scottmcm proposed for discussion:
Now that we have
ptr::addr_of_mut!, the 2024 edition would be a great time to do @RalfJung's idea from #53639 (comment):Disallow
&MY_STATIC_MUTand&mut MY_STATIC_MUTentirely.
ptr::addr_of_mut!(MY_STATIC_MUT)could even be safe – unlike taking a reference which isunsafeand often insta-UB – and helps encourage avoiding races in the accesses, which is more practical than trying to avoid the UB from concurrent existence of references.(Maybe people will end up just doing
&mut *ptr::addr_of_mut!(MY_STATIC_MUT)anyway, but we can't force them to drink.)
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe