Design meeting 2024-04-10: Rust 2024 Edition Review

--- title: "Design meeting 2024-04-10: Rust 2024 Edition Review" tags: ["T-lang", "design-meeting", "minutes"] date: 2024-04-10 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-04-10 url: https://hackmd.io/b3nZ702AT4WexBt_rHPlCA --- # 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 * Disallow references to static mut * Change merged. Migration (and documentation) needs attention: https://github.com/rust-lang/rust/issues/114447#issuecomment-2018907981 ### Implementation in progress #### RPIT lifetime capture * RPIT lifetime capture * "In terms of timeline, it's probably going to be tight." * https://github.com/rust-lang/rust/issues/117587 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 * Cargo: Remove implicit features. * Eric Huss is taking care of this? * https://github.com/rust-lang/rfcs/pull/3491 * Cargo: Public/private dependencies * Needs compiler work. davidtwco: "still working away on it. Shouldn't be too long." * epage: "if this doesn't make this Edition, it doesn't mean people can't benefit from the work until the next Edition. At worst it will be an opt-in" * Cargo: MSRV-aware resolver by default * https://github.com/rust-lang/cargo/issues/9930. * "remaining work is small." largest item is the bike shedding on naming in https://github.com/rust-lang/cargo/issues/13540 #### `Box<[T]>: IntoIter` * Box<[T]> (and Box<[T; N]>) IntoIter * No RFC or FCP, but likely to be approved? * PR still in draft: https://github.com/rust-lang/rust/pull/116607 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. * Style change approved, but no work done on rustfmt yet * https://github.com/rust-lang/rust/pull/114764#issuecomment-1909223649 No owner? No impl yet. ### Still in design phase #### Temporary lifetimes in tail expressions * Temporary lifetimes in tail expressions * RFC in FCP, but blocking concern about unsafe pointer code * https://rust-lang.zulipchat.com/#narrow/stream/403629-t-lang.2Ftemporary-lifetimes-2024/topic/Blocking.20concern.20-.20unsafe.20code/near/432472964 * blocking concern not considered blocking, but still needs impl. needs crater runs/exploration too. #### 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 * much discussion still ongoing. concern on "safe" keyword. * no implementation yet. * comment by author: https://github.com/rust-lang/rfcs/pull/3484#issuecomment-2033297830 * time pressure? * fine to cancel/delay three years? 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 * Original owner doesn't have time for this. Looking for new owner. - There's a lang consensus on how to do this. - https://github.com/rust-lang/rust/issues/64586#issuecomment-1865477110 - Nadri doesn't have the bandwidth for the work. - https://github.com/rust-lang/rust/issues/64586#issuecomment-1940415707 - https://github.com/rust-lang/rust/issues/105647#issuecomment-1937869635 - Jules Bertholet has picked this up. - https://github.com/rust-lang/rust/pull/122978 - Tracking issue: https://github.com/rust-lang/rust/issues/123076 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 * Change merged. Migration (and documentation) needs attention: https://github.com/rust-lang/rust/issues/114447#issuecomment-2018907981 Implementation in progress: * RPIT lifetime capture * "In terms of timeline, it's probably going to be tight." * https://github.com/rust-lang/rust/issues/117587 * Cargo: Remove implicit features. * Eric Huss is taking care of this? * Cargo: Public/private dependencies * Needs compiler work. davidtwco: "still working away on it. Shouldn't be too long." * epage: "if this doesn't make this Edition, it doesn't mean people can't benefit from the work until the next Edition. At worst it will be an opt-in" * Cargo: MSRV-aware resolver by default * https://github.com/rust-lang/cargo/issues/9930. * "remaining work is small." largest item is the bike shedding on naming in https://github.com/rust-lang/cargo/issues/13540 * Box<[T]> (and Box<[T; N>) IntoIter * No RFC or FCP, but likely to be approved? * PR still in draft: https://github.com/rust-lang/rust/pull/116607 Needs implementation: * unsafe attributes * FCP just finished. no implementation and migration? * Rustfmt: Enable overflow_delimited_expr by default. * Style change approved, but no work done on rustfmt yet * https://github.com/rust-lang/rust/pull/114764#issuecomment-1909223649 Still in design phase: * Temporary lifetimes in tail expressions * RFC in FCP, but blocking concern about unsafe pointer code * https://rust-lang.zulipchat.com/#narrow/stream/403629-t-lang.2Ftemporary-lifetimes-2024/topic/Blocking.20concern.20-.20unsafe.20code/near/432472964 * 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. * unsafe extern blocks * much discussion still ongoing. concern on "safe" keyword. * no implementation yet. * comment by author: https://github.com/rust-lang/rfcs/pull/3484#issuecomment-2033297830 * time pressure? * fine to cancel/delay three years? * Never: Make `!` fall back to `!` * ? * Never: don't special-case diverging blocks * ? 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: - Lifetime Capture Rules 2024. - 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. - Reserve `gen` keyword. - We've merged the RFc and reserved the keyword. - Include `Future` and `IntoFuture` in prelude. - The change landed in Rust 2024. - https://github.com/rust-lang/rust/issues/121041 - There is a migration lint needed (Nils). - https://rust-lang.zulipchat.com/#narrow/stream/268952-edition/topic/2024-03.20update/near/429080467 - Remove `RustcEncodeable` / `RustcDecodable` from prelude. - Done. - https://github.com/rust-lang/rust/issues/116016 - Disallow references to static mut. - This has landed in Rust 2024 on nightly as of #117556 (on the basis of a [2023-09-05 meeting consensus](https://github.com/rust-lang/rust/issues/114447#issuecomment-1707177536)) . - https://github.com/rust-lang/rust/issues/117556 - Make `unsafe_op_in_unsafe_fn` warn-by-default. - We made this warn-by-default in Rust 2024 in #112038 and added the migration in #119948. - https://github.com/rust-lang/rust/issues/112038 - https://github.com/rust-lang/rust/issues/119948 - Match ergonomics. - There's a lang consensus on how to do this. - https://github.com/rust-lang/rust/issues/64586#issuecomment-1865477110 - Nadri doesn't have the bandwidth for the work. - https://github.com/rust-lang/rust/issues/64586#issuecomment-1940415707 - https://github.com/rust-lang/rust/issues/105647#issuecomment-1937869635 - Jules Bertholet has picked this up. - https://github.com/rust-lang/rust/pull/122978 - Tracking issue: https://github.com/rust-lang/rust/issues/123076 - Unsafe Extern Blocks. - This is in proposed FCP will all boxes checked. - But Niko has raised a concern over the keyword. - https://github.com/rust-lang/rfcs/pull/3484 - Macro matcher fragment specifiers edition policy. - We RFCed the policy and accepted it. - Someone needs to apply this policy to e.g. `expr`. - We're seeing if Vincenzo has interest in this (WG-macros). - New `Range` types. - We discussed this in triage.