Design meeting 2024-04-17: Topic

--- title: "Design meeting 2024-04-17: Edition 2024 review" tags: ["T-lang", "design-meeting", "minutes"] date: 2024-04-17 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-04-17 url: https://hackmd.io/Fcy0KRFISuGYeGEfWZ7BfQ --- # Design meeting: Edition 2024 review ## Attendance - People: TC, tmandry, CE, scottmcm, Urgau, eholk, pnkfelix ## Meeting roles - Minutes, driver: TC ## Tracking ### "Tracking issue for RFC 1977: public & private dependencies" rust#44663 **Link:** https://github.com/rust-lang/rust/issues/44663 ### "Tracking Issue for RFC 3501: Edition 2024" rust#117258 **Link:** https://github.com/rust-lang/rust/issues/117258 ### "Tracking Issue for Lifetime Capture Rules 2024 (RFC 3498)" rust#117587 **Link:** https://github.com/rust-lang/rust/issues/117587 ### "Tracking Issue for the 2024 prelude" rust#121042 **Link:** https://github.com/rust-lang/rust/issues/121042 ### "Tracking Issue for match ergonomics 2024" rust#123076 **Link:** https://github.com/rust-lang/rust/issues/123076 tmandry: This feels like a reasonable set of decisions. It would help to see this implemented and to see the migration. TC: I'll suggest to Jules to go ahead with the implementation and then we'll be able to discuss it on that basis. tmandry/TC: It'd be good to see an RFC here also. tmandry: The RFC could use most of the content of the design document. TC: +1. ### "Tracking Issue for `precise_capturing`" rust#123432 **Link:** https://github.com/rust-lang/rust/issues/123432 Near-consensus for `use<>` syntax. ### "Tracking Issue for RFC 3593: Reserve unprefixed guarded string literals in Edition 2024" rust#123735 **Link:** https://github.com/rust-lang/rust/issues/123735 TC: Does this have implications for style, CE? CE: Not really. TC: OK, we'll mark that item N/A then. It was already checked off. ### "Tracking Issue for RFC 3606: Drop temporaries in tail expressions before local variables" rust#123739 **Link:** https://github.com/rust-lang/rust/issues/123739 pnkfelix: I'll own this one. I've assigned it to myself. ### "Tracking Issue for RFC 3550: New range types" rust#123741 **Link:** https://github.com/rust-lang/rust/issues/123741 TC: The FCP is here: https://github.com/rust-lang/rfcs/pull/3550#issuecomment-1908544755 TC: When NM checks his box, and Mara resolves the concern, which she said she'll do when the RFC adds the open question, then this will move into FCP. ### "Tracking Issue for updating `expr` macro fragment specifier for Rust 2024" rust#123742 **Link:** https://github.com/rust-lang/rust/issues/123742 eholk: This is mostly on track. Have been pair programming with Vincenzo. https://github.com/rust-lang/rust/issues/123742 eholk: There was a question about how to migrate, but I think at this point I'm in favor of the conservative choice made in the policy RFC. TC: Vincenzo had asked about whether other fragment specifiers need to be updated. It had been an open item for someone to check for these. Other fragments? - `unsafe extern` blocks probably needs an update to `item`. - unprefixed guarded string literals? `###"foo"###`. eholk: It'd be nice if there were a more automated way to find these. CE: The only current way is manually auditing the code. ### "Tracking Issue for RFC 3484: Unsafe Extern Blocks" rust#123743 **Link:** https://github.com/rust-lang/rust/issues/123743 TC: Santiago offered to pick this one up. TC: The RFC is pending a concern about choice of keyword. tmandry: On initial reaction, the `safe` keyword still makes the most sense here. The proposal makes sense to me unless someone puts forward more of an argument here about what we might want in the future. pnkfelix: I don't care to deviate here on the keyword. ### "Tracking Issue for "don't special case diverging blocks"" rust#123747 **Link:** https://github.com/rust-lang/rust/issues/123747 TC: The next step here was scottmcm was going to check with Caleb and company about not adding semicolons in these cases in all editions, as that would help in resolving his concern about moving forward here. ### "Tracking Issue for making `!` fall back to `!`" rust#123748 **Link:** https://github.com/rust-lang/rust/issues/123748 TC: The FCP here needs one more check box: https://github.com/rust-lang/rust/pull/123508 tmandry: I'm checking my box here. TC: This will move into FCP then. And Waffle is working on the implementations and the lints. ### "Tracking Issue for Rust 2024: Cargo MSRV-dependent dependency version resolution" rust#123749 **Link:** https://github.com/rust-lang/rust/issues/123749 ### "Tracking Issue for Rust 2024: Cargo remove implicit features" rust#123750 **Link:** https://github.com/rust-lang/rust/issues/123750 ### "Tracking Issue for Rust 2024: rustfmt enable `overflow_delimited_expr`" rust#123751 **Link:** https://github.com/rust-lang/rust/issues/123751 tmandry: It looks like the option is still unstable and would need to be stabilized. TC: This seems to be looking for a confirmed owner. ### "Tracking Issue for Rust 2024: Cargo deprecations" rust#123754 **Link:** https://github.com/rust-lang/rust/issues/123754 ### "Tracking Issue for RFC 3325: unsafe attributes" rust#123757 **Link:** https://github.com/rust-lang/rust/issues/123757 TC: This is definitely looking for an owner. We've accepted the RFC. tmandry: I would really like to see this. I'm not sure how non-trivial the implementation. tmandry: We should have a retrospective on how this managed to drag out for so long and how we could avoid that in the future. TC: There is the policy about, after a certain point, requiring concerns to be seconded. We should perhaps lean more heavily on that. tmandry: +1. ### "Tracking Issue for Rust 2024: Disallow references to static mut" rust#123758 **Link:** https://github.com/rust-lang/rust/issues/123758 pnkfelix: How critical is it that we make this a hard error in the edition, given that we have the lint? tmandry: Good question. I'm also interested in how much code would break. TC: We should push through this FCP: https://github.com/rust-lang/rust/issues/123060 tmandry: I'll check my box. pnkfelix: Same. This should have been included. TC: This will go into FCP. ### "Tracking Issue for Rust 2024: `Box<[T]> (and Box<[T; N]>): IntoIter`" rust#123759 **Link:** https://github.com/rust-lang/rust/issues/123759 CE: This uses a language hack similar to one we already made. The implementation looks fine to me. CE: The PR needs to be taken out of draft, it needs to be reviewd -- I'll review it -- and then FCPed on the libs-api side. TC: This will need lang sign-off also on that hack. CE: Actually, I'll pick this up since clarfonthey is dropping the draft. ### "Tracking Issue for Rust 2024: rustfmt style editions" rust#123799 **Link:** https://github.com/rust-lang/rust/issues/123799 ### "Tracking Issue for Rust 2024: rustfmt use version sort" rust#123800 **Link:** https://github.com/rust-lang/rust/issues/123800 ### "Tracking Issue for Rust 2024: rustfmt change sort to Unicode-aware "non-lowercase before lowercase"" rust#123802 **Link:** https://github.com/rust-lang/rust/issues/123802 ### "Tracking Issue for Rust 2024: Reserve `gen` keyword" rust#123904 **Link:** https://github.com/rust-lang/rust/issues/123904 ### "Tracking Issue for Rust 2024: Make `unsafe_op_in_unsafe_fn` warn-by-default" rust#123916 **Link:** https://github.com/rust-lang/rust/issues/123916 tmandry: I'll ping a possible implementor about fixing the bug in the migration. ### "Tracking Issue for Rust 2024: Rescope temporary lifetimes with respect to `else`" rust#124085 **Link:** https://github.com/rust-lang/rust/issues/124085 TC: We wanted this to land in nightly with a gate so we could better evaluate the migration. (The meeting ended here.)