Rust 2024 survey

[nikomatsakis]

Summary

The Rust 2024 edition is coming soon! Any land changes should be RFC'd this year. Let's do a survey of things that could be done over the edition so that we can start tracking as we go into the summer.

Background reading

Include any links to material that folks ought to try to read before-hand.

About this issue

This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.

[joshtriplett]

Some potentially useful links:

• https://blog.rust-lang.org/inside-rust/2022/04/04/lang-roadmap-2024.html
• https://github.com/rust-lang/rust/labels/A-edition-2024
• https://github.com/rust-lang/rust/labels/lang-team-202x-edition

[nikomatsakis]

Scheduled for 2023-06-28 and placeholder doc created

[Lokathor]

the unsafe extern blocks RFC would be edition sensitive, rust-lang/rfcs#3439

[Jules-Bertholet]

rust-lang/rust#59878 would be nice to fix, if negative impls can be stabilized on time

[RalfJung]

rust-lang/rfcs#3325 is intended to be edition sensitive.

Not sure if there is any point in giving another shot at "removing long-deprecated items that are unsound or almost impossible to use soundly" (mem::uninitialized, before_exec).

[Jules-Bertholet]

Some more open RFCs that are potentially edition-sensitive:

• Conversions: FromLossy and TryFromLossy traits rfcs#2484 (deprecate as?)
• Unsafe statics rfcs#2937 (deprecate static mut?)
• Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods rfcs#3240
• RFC: Aligned trait rfcs#3319 (future possibility: ?Sized → ?Aligned)
• Avoid non-local definitions in functions rfcs#3373
• Extern types v2 rfcs#3396
• Explicit move binding mode rfcs#3410 (future possibility)

Open issues not previously mentioned:

• Much of https://github.com/rust-lang/rust/labels/A-edition-2018-lints
• Much of https://github.com/rust-lang/rust/labels/C-future-compatibility
• Tracking issue for promoting ! to a type (RFC 1216) rust#35121 (inference fallback)
• Tracking issue for #[doc(cfg(…))], #[doc(cfg_hide(…))] and doc_auto_cfg rust#43781 (doc_auto_cfg)
• Reject bounds in type aliases with edition 2024 rust#49441
• Tracking issue for ..X, and ..=X (#![feature(half_open_range_patterns)]) rust#67264
• Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585) rust#71668
• Tracking Issue for infallible promotion rust#80619
• Tracking Issue for RFC: Supertrait Item Shadowing rust#89151 (RFC future possibility)
• Tracking Issue for #[deprecated_safe] attribute rust#94978
• Tracking Issue for strict_provenance rust#95228 (deprecate pointer-integer as casts?)
• Make mem::uninitialized inaccessible in future editions rust#98862
• overflowing_literals should have an option for "ignore signed overflows" rust#99195 and repr(C) enums with a variant that overflows the native enum type should warn rust#108069 (make overflowing_literals deny or a hard error?)
• Tracking Issue for refined trait implementations rust#100706

[tgross35]

I know there was some discussion about changing the Range/Iter/IntoIterator/Copy fiasco at some point, but I don't believe a concrete proposal came out of it, or if it is even "fixable"

[bstrie]

@tgross35 I think the Range situation is improvable, although naturally having an RFC is a prerequisite and nobody's going to hold up the edition if an RFC doesn't materialize. I have some thoughts in that area that might lead to an RFC, although I need to page the discussion back into my head.

[tgross35]

I did find some discussion about this rust-lang/rfcs#2848. It seems like the kind of thing where somebody just needs to start writing an RFC and see how well it sticks.

@bstrie if you want to throw some loose ideas into a HackMD document, I don't mind helping formulate them into an RFC (I'm sure others would join too)

[Jules-Bertholet]

https://github.com/rust-lang/rust/labels/WG-epoch also merits review

[fmease]

I know this issue is not the right place (the meeting has already happened as far as I can tell) but since there isn't a proper Zulip stream yet (ah, there is one), I'm just gonna nominate the (breaking) feature lazy_type_alias here for inclusion into Rust 2024. It still needs some polish though.

This directly addresses the following point found at the bottom of the HackMD doc:

other things that came up after the meeting

• Remove where clauses on type aliases or make them work.

Edit: I'm gonna open a Zulip topic for this later, too. Edit: Zulip topic.

[tgross35]

@bstrie I don't know whether you had time to put anything together, but I started a rough outline https://hackmd.io/@8W5l8q6-Qyyn_vKh2-L0RQ/SJ0sBpb22. It should be open for editing if anyone wants to contribute (discussion should probably happen in comments in the doc so as to not derail this thread).