Try   HackMD

Rust 2024 Edition Review

Attendance

  • People: TC, Mara, Waffle, scottmcm, Josh, eholk, Nadri, NM. ehuss

Meeting roles

  • Minutes, driver: TC

Project board

https://github.com/orgs/rust-lang/projects/43

2024 Edition Update blog post from ehuss (2024-03-22)

https://blog.rust-lang.org/inside-rust/2024/03/22/2024-edition-update.html

Meta-points on edition

Is 2024 realistic

scottmcm: The top thing is probably determining whether Rust 2024 is realistic. Or we could start punting things out of the edition. We should disincentize people from trying to get things in at the last moment as has been happening.

TC: Maybe there's a structural issue here. Three years is just slightly too long for the wheel to keep turning, in terms of the train model.

Mara: +1. The Range types are agood example of this. It was dropped in 2020 then picked back up recently.

Josh: +1. One problem is that it's long enough that people change. It feels like we need a team that's responsible for this all the time, and then it would stay in practice.

TC/Mara: We've been pleasantly surprised by how much has landed in the last two months.

TC: There is some value in a forcing function. Things that had been in progress for many years have now landed all at once. There are tradeoffs here.

Niko: When we did the 2018 edition we did a few betas. We could push the edition as far back as possible. I feel we should do an edition here.

The edition working group is short staffed

Mara: I'm not sure the group is able to drive things hard enough here.

Mara: Someone needs to make sure all the boxes are checked and "feel some stress" when there are gaps. Things don't have a clear owner, split between lang and wg-edition and others.

NM: It does feel like we need to extablish a clear owner here.

Josh: It does feel like cross-team coordination is the main challenge. Where things fall within one team, those seem well handled. The cross-team things don't always have a clear answer.

Cross-team coordination

TODO.

Edition items

Done, but could use polishing:

Macro fragment policy

  • Macro fragment policy
    • Policy merged.
    • Might still need to be applied to things. Someone in #wg-macros looking into it as of 2 days ago.

eholk: Vincenzo is looking into this.

unsafe_op_in_unsafe_fn

  • Making unsafe_op_in_unsafe_fn a warning by default
    • Done, including migration. But migration result has bad formatting; could use attention.

Need migration lint

RustcEncodable etc.

  • Removing RustcEncodable and RustcDecodable from the prelude
    • merged, but still needs a migration lint.

Future / IntoFuture

  • Include Future and IntoFuture in the prelude
    • merged, but still needs a migration lint (similar to the one in 2021). Nobody is working on this.

NM: What do we need to do for this?

Mara: We had FromIterator in 2021. It's like that.

Josh: I'm not clear what the migration lint needs to be here. What code needs to change?

Mara: If you import from another ecosystem crate it will break.

Waffle: Future has a method Pin<&mut Self>, so this will be different than IntoIterator.

Mara: We also had TryFrom and TryInto in 2021.

Josh: So the migration is deleting imports of compatible versions of the trait.

Mara: Or qualifying them.

Josh: Some people don't use the migration lints. They just change the edition and start compiling. Would be good if we could migrate in a fashion that generates the code people want.

gen keyword

  • Reserve the gen keyword
    • has been reserved, but not "done": but no migration lint.

TC: CE is aware of this and is working on it.

References to static mut

Implementation in progress

RPIT lifetime capture

TC: We've landed the RFC and the impl in Rust 2024. This has a dependency on precise capturing. RFC is progress on that, design meeting on 2024-04-24.

Cargo issues

Box<[T]>: IntoIter

TC: This needs work from lang?

Mara: Yes, we need lang help on the migration here.

Waffle: My read is that this is not being actively driven.

Needs implementation:

unsafe attributes

FCP just finished. no implementation and migration

Owner? Ralf? Probably not going to implement it.

scottmcm: I wouldn't be torn up if the hard error didn't happen until Rust 2027.

Josh: We'll want to impl unsafe attributes in all editions anyway; if the error-by-default slips to a future edition, that's OK.

Rustfmt: Enable overflow_delimited_expr by default.

No owner? No impl yet.

Still in design phase

Temporary lifetimes in tail expressions

New range types

  • some design/migration questions still open
  • not all alternatives explored (e.g. a type inferrence solution) (time pressure?)
  • might need more time to allow the ecosystem to adapt to the new types before the edition stabilizes.

Mara: I feel like the decisions are being driven by time pressure. I feel like we're dismissing solutions here.

Unsafe extern blocks

NM: Edition not that important. edition is icing on the cake, but 99% of the benefit is available without an edition.

Waffle: I think the edition is an important point here because if we don't do the edition we'll have to live with the default being unsafe and that could be confusing. One of the important points here is that the edition makes this a very explicit change.

NM: I agree we'll eventually want an edition. But it's a two step process.

scottmcm: We lint about something then make the lint a hard error over an edition. For things like this, if we slip by one edition, that's not a big deal.

NM: We should look for opportunities to guide people into the state we want them to be in then to use the edition to formalize it.

Never: Make ! fall back to !

Clear owner: waffle.

TC: Waffle is working on it.

Waffle: The change itself is ready, and I'm working on the lints, which are the second part. The design of the lints is clear enough, so I am sure we can make them.

Never: don't special-case diverging blocks

Clear owner: waffle.

TC: Waffle is working on this and we started an FCP in the last meeting.

Match ergonomics

Nadri: Jules Bertholet took over and has been making good progress on the impl side

Nadri: they're implementng a few possibilities, but there's some non-controversial things in there I'm pretty confident we can land in time.

Nadri: on the approval side, lang approved the non-controversial things at least

Table

Categorization:

  • Owner:
    *
  • Estimate: Is this…
    • 2024 EOY – on track for end of year
    • 2025 Q1 – could use a bit of extra time
    • ?? – hard to say
  • Priority:
    • High
    • Medium
    • Low (Default)
  • Requires edition?
    • Yes
    • No
  • Requires more exploration (e.g. crater)? – (I think this can be reflected in estimate)
    • Yes
    • No
Item Owner Committed Estimate Priority Requires edition?
RPIT lifetime capture TC high yes
Reserve the gen keyword TC/Oli/CE on track high yes
Never: Make ! fall back to ! waffle X medium yes
Never: don't special-case diverging blocks waffle X medium yes
Temporary lifetimes in tail expressions niko
New range types pitaj ??
Updating expr fragment eholk/Vincenzo on track
Making unsafe_op_in_unsafe_fn default tmandry on track
Removing Rustc*codable from the prelude jhpratt
Include Future and IntoFuture in the prelude nils? yoshuawuyts?
Disallow references to static mut scottmcm?
Cargo: Remove implicit features. on track
Cargo: MSRV-aware resolver by default
Box<[T]> (and Box<[T; N]>) IntoIter
Rustfmt: Enable overflow_delimited_expr
Match ergonomics Jules Bertholet
unprefixed guarded string literals #3593 pitaj
Cargo: Public/private dependencies could use opt-in
unsafe attributes RalfJ? could use lints
unsafe extern blocks Lokathor? could use lints

Meta

NM: Mara, what do you most want out of this meeting?

Mara: It was good to know the items that may not be critical fo the editoin. It'd also be good to know whether there's anything that makes an edition urgent, in terms of whether we could delay the edition.

Mara: Are the priority items really going to happen?

TC: Yes.

NM: The first two especially.

Josh: I'd set a high bar for delaying the edition. This will already be a larger edition than Rust 2021.

Mara: It adds pressure if the next edition is as far out as Rust 2027. That's what concerns me.

NM: I don't really want to relitigate that though.

Josh: We shouldn't relitigate it in this meeting, though I'd generally be in favor of that.

NM: What timeline do you have in mind:

ehuss: End of May for implementation.

NM: What does that include?

ehuss: Implementation and migration lints but not documentation.

ehuss: The currently anticipated deadlines are:

  • End of Apr 19: Know who the owners are (or cut)
  • Beginning of May: code complete
    • can still be fixing bugs
    • if it's not there,
  • End of May: Implementation deadline
    • New behavior when using --edition 2024
    • Migrations lints
  • June for crater testing
  • July for public beta testing
  • August/sept beta train
  • October: release on stable.

TC: Niko has proposed pushing the release back to the end of the year or January. If that allowed work to get in that is close, that seems worth it in terms of letting contributors check things off their list. Otherwise these items kind of die, and we'll be back here in three years saying, "wait, where did we leave that? Someone should write a document." Many things that have been in the works for years have landed recently, so the forcing function is working.

NM: We should check in at the beginning of May that things are 80% there.

Edition owner

NM: Someone needs to own getting the edition out.

Mara: It's important to me this happens, but I'm ambivalent about doing it. Whoever owns it needs to own it and take full responsibility for this happening.

TC: So much of this is lang that I think I'd prefer to take this, if that works for Mara.

Mara: +1.

all: +1.

TC: On whatever date we set out, there will be an edition.

Consensus: TC will take this.

(The meeting ended here.)

Appendix: Summaries of status

Mara's summary of status:

Done, but could use polishing:

  • Macro fragment policy
    • Policy merged.
    • Might still need to be applied to things. Someone in #wg-macros looking into it as of 2 days ago.
  • Making unsafe_op_in_unsafe_fn a warning by default
    • Done, including migration. But migration result has bad formatting; could use attention.

Need migration lint:

  • Removing RustcEncodable and RustcDecodable from the prelude
    • merged, but still needs a migration lint.
  • Include Future and IntoFuture in the prelude
    • merged, but still needs a migration lint (similar to the one in 2021). Nobody is working on this.
  • Reserve the gen keyword
    • has been reserved, but no migration lint.
  • Disallow references to static mut

Implementation in progress:

Needs implementation:

Still in design phase:

Stuck?:

  • Match ergonomics

    • Original owner doesn't have time for this. Looking for new owner.

    Nadri: Jules Bertholet took over and has been making good progress on the impl side

TC summary of status:

Last changed by 
 
Rust Lang Team
Language Design team for the Rust programming language
0
236

Read more

Lang/RfL meeting 2025-07-30

People:

Jul 31, 2025
Lang/RfL meeting 2025-07-30 (duplicate)

People:

Jul 31, 2025
Triage meeting 2025-07-30

Meeting date: 2025-07-30

Jul 31, 2025
Design meeting 2025-07-30: In-place initialization

Thanks for coming to the in-place init design meeting. Before reading this document, please start by reading the project goal proposal:

Jul 31, 2025
Read more from Rust Lang Team
Published on HackMD