---
title: "Design meeting 2024-01-10: 2024 Edition Planning"
date: 2024-01-10
tags: ["T-lang", "design-meeting", "minutes"]
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-01-10
url: https://hackmd.io/f2ROqi22ToKTfzUnFoROug
---
# 2024 Edition Planning
## Minutes
People: TC, tmandry, eholk, Josh, fmease, scottmcm, pnkfelix
Minutes: TC
## Background materials
This meeting:
https://github.com/rust-lang/lang-team/issues/248
Rust 2024 edition project board:
https://github.com/orgs/rust-lang/projects/43/views/5
Rust 2024 survey document:
https://hackmd.io/itGzgM1fQl-oh4d1iP8sFg
2023-11-15 design meeting about Rust 2024 edition review:
https://hackmd.io/KF7t6VlCTHKCO0y7EY7Rrw
## Discussion items
### Priorities for 2024 Edition
tmandry: In the last meeting, we decided to separate out items that we considered to be *priorities*, things that we would work to make happen.
tmandry: Currently I've nominated one item as a *priority* for the lang team in 2024, the Lifetime Capture Rules ([RFC #3498](https://github.com/rust-lang/rfcs/blob/master/text/3498-lifetime-capture-rules-2024.md)). Does anyone object to this? Are there others that should be nominated as well?
TC: +1.
(Discussion about the dependencies of this and the status.)
TC: This being marked as a priority means that we'll allocate the bandwidth needed to work toward finding *some* solution for any dependencies.
tmandry: Agree with this framing.
*Consensus*: Let's leave this marked as a priority.
### `gen` keyword for generators
Are there other items we'd like to prioritize?
eholk: If we don't introduced the `gen` keyword, would we need to wait for Rust 2027 to introduce generators?
JT: Strictly speaking, no, people could write `k#gen`.
fmease: We haven't even implemented it (`k#`) yet.
TC: Surprisingly, we didn't even accept the RFC for `k#`. We accepted the RFC for reserving all the syntax like that. We closed the specific RFC for `k#`. The RFC we closed is also the one that discusses preferring to not reserve keywords.
Here's the one we accepted:
https://github.com/rust-lang/rfcs/pull/3101
Here's the one for `k#` that we closed:
https://github.com/rust-lang/rfcs/pull/3098
eholk: It's possible we'll have generators or the full `gen` RFC ready in time.
TC: There are significant open issues, such as over pinning. Depending on the timeline we're targetting, that could be a challenge. We could always reduce the RFC scope, however. The important part for the edition is reserving the keyword.
JT: We should probably make sure the RFC doesn't finalize a syntax for `gen fn`.
TC: Agreed. We need to redraft various things in the RFC.
*Consensus*: Let's mark the `gen` RFC as a priority, keeping in mind the main priority is doing what we need to do to reserve the keyword.
### Nominated issues
#### Reject bounds in type aliases with edition 2024 [#49441](https://github.com/rust-lang/rust/issues/49441)
fmease: The plan is to make lazy aliases the default in Rust 2024. We still need to do implementation work and run crater.
*Consensus*: Let's downgrade this to "would consider" as a fallback since we're waiting on implementation work.
#### Refined lifetimes and super let ([draft RFC](https://hackmd.io/wU_CYnUeT7G7hYazna6vDQ))
tmandry: This isn't at a stage that I feel that we're going to get it for Rust 2024.
TC: There's been extensive discussion in the Zulip stream for this. There are a lot of degrees of design freedom here that would need to be discussed.
tmandry: Should we downgrade this to "would consider"?
*Consensus*: Let's downgrade this to the top of "would consider".
(scottmcm: I would really like an intuitive set of rules, but agree that it needs more status clarity before we can commit to it.)
#### Tracking issue for indirect_structural_match compatibility lint [#62411](https://github.com/rust-lang/rust/issues/62411)
"RFC: constants in patterns" https://github.com/rust-lang/rfcs/pull/3535
tmandry: The RFC for this is in FCP.
tmandry: Over the edition, we'd make this lint into a hard error.
TC: Makes sense to me even aside from the RFC. We had talked about moving a number of these future-compat lints to a hard error.
*Consensus*: Let's move to "would consider".
#### Tracking issue for promoting ! to a type (RFC 1216) [#35121](https://github.com/rust-lang/rust/issues/35121)
TC: The exciting progress here is that we can lint against the problematic cases of fallback in all editions. Then the question is what we want to do with that lint in 2024?
tmandry: Yes, that progression makes sense to me. Once that lint is implemented we'll know more. Do we want to make this priority for 2024?
scottmcm: If we have a plan, I'd love to make this a priority.
tmandry: It does seem we have a plan here.
TC: The lint is for cases like this:
```rust
if false { panic!() } else { transmute::<_, _ /* ?0 */>(()) }
// later in fallback: ?0 := ()
// after ! stabilization: ?0 := !
```
scottmcm: It might be time to make compromises to land this, if we have to.
scottmcm: That lint would be a good idea on every edition regardless, as it's surprising.
scottmcm: We could e.g. add an empty enum and make that lang item for `!`.
tmandry: We have stable APIs that return `-> !`. People can rely on that, so that may limit our options.
pnkfelix: Regarding scottmcm's point, has anyone done a crater run to see the scope of impact? But tmandry is saying that the scope of impact on the stdlib is itself significant.
scottmcm: It would need to also e.g. add coercions on function calls.
JT: The breakage in existing unstable code is the only thing I'd be concerned about. If we can unify it with `Infallible` and not break unstable code, we could sacrifice other properties.
tmandry: I propose we mark it as a priority. This discussion shows we care about it.
scottmcm: When we talk about stable code, are we excluding uses of the never type hack?
scottmcm: Personally, I'm willing to consider it a bug in the feature gating.
TC: Agreed, though the never type hack is a particularly interesting case of such feature gate leakage because it is such a natural consequence of intended features.
tmandry: Dependent on the actual impact, I'd be fine with that.
JT: We should also think about pattern types, as there is some overlap here, and we could desugar certain uses of never to uses of pattern types.
scottmcm: Using pattern types will not be able to affect layout in the way that using a different type can.
TC: Going back to tmandry's point, it seems this is a priority.
scottmcm: +1. We've literally stabilized it twice and backed it out twice. Seems like a priority.
*Consensus*: Let's mark this as a priority.
---
*Post-meeting notes*:
TC: This is the "never type hack":
```rust
#[doc(hidden)]
pub trait NeverTypeHack {
type Output;
}
impl<T> NeverTypeHack for fn() -> T {
type Output = T;
}
pub type Never = <fn() -> ! as NeverTypeHack>::Output;
```
Here are more details about the never type situation:
https://github.com/rust-lang/never-type-initiative
We also recently discussed the situation with the never type at some length in the 2023-12-06 planning meeting:
https://hackmd.io/jNCHJnQrQGiXwVPAmmdYCg#%E2%80%9Cincorrect-UB-when-when-a--place-is-constructed-but-not-loaded%E2%80%9D-rust117288
#### Make mem::uninitialized inaccessible in future editions [#98862](https://github.com/rust-lang/rust/issues/98862)
scottmcm: We've defanged this extensively, and we have lints about all the problematic cases we know about.
pnkfelix: Isn't this T-libs?
scottmcm: It's already deprecated. There's nothing else libs can do here. So it's up to us.
JT: ...
tmandry: The only downside I can see is that there's not an automated migration. The alternative is making this a deny-by-default lint.
JT: I'd be worried more if there hadn't been a future-incompat lint for years.
scottmcm: I think I want it to stay in name resolution. Getting an error message that says that it doesn't exist may be more confusing. We could put a strength attribute on the deprecation attribute. This could be edition dependent.
JT: We've recently added mechanisms to the compiler to recognize things that don't exist, e.g. for CFGs, and to say "this would exist if you added this feature". We could use the same machinery here.
scottmcm: Strictly speaking, there is a migration path that could be automated. It's just that people shouldn't do it.
tmandry: Agreed I'm not worried about it due to how long we've been linting.
scottmcm: Do we have a specific proposal here for what to do?
tmandry: I have a clear mental idea, but we should write it out.
TC: The priority we set is about the bandwidth we apply toward developing a specific proposal.
tmandry: The proposal here is to prioritize it at the "Accept" level.
scottmcm: Do we really make anything better by removing this? Won't people who haven't updated by now just find a way to keep doing the wrong thing?
tmandry: Moving to the new edition provides some "carrot" here.
TC: And forcing people to do something obviously horrible to work around this without actually fixing it may provide some "stick".
*Consensus*: Let's move this to "Accept". We're not concerned about making this a friendly migration. Let's minimize the amount of work we do here.
### "Would consider" issues
Does anyone care about one of these enough to follow up on them?
(Not discussed.)
## Process going forward
tmandry: Going forward, I'd like to discuss the prioritized items in the triage meetings, and for any items that are marked as "discuss" where we should determine the priority, I'd like us to go through those in triage also.
(No objections.)
*Consensus*: We'll do a "tick" in the triage calls to check on progress on the prioritized items, and we'll discuss any 2024 items where we need to discuss the appropriate priority level.
(The meeting ended here.)
Sign in with Wallet
Connect another wallet