add a "future" edition

[davidtwco]

This idea has been discussed previously on Zulip (though what I've implemented isn't exactly the "next"/"future" editions proposed in that message, just the "future" edition). I've found myself prototyping changes that involve edition migrations and wanting to target an upcoming edition for those migrations, but none exists. This should be permanently unstable and not removed.

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[oli-obk]

cc @rust-lang/edition

[ehuss]

Can you say more about why any future changes would need to be tied to any edition? The kind of expected development workflow would be to keep new features behind a feature gate. Only when it looks like it is definitely ready to go in the edition would it add edition gates, and only once were are ready to stabilize would the feature gate be removed.

[davidtwco]

Can you say more about why any future changes would need to be tied to any edition? The kind of expected development workflow would be to keep new features behind a feature gate. Only when it looks like it is definitely ready to go in the edition would it add edition gates, and only once were are ready to stabilize would the feature gate be removed.

In rust-lang/rfcs#3729, I describe some edition migrations that the RFC would require - I'm working on an experimental implementation of that RFC, and it's all behind a feature gate like you would expect, but I still want to be able to implement the behaviour for edition N and edition N+1 and write the tests confirming that behaves like it should.

[fmease]

Quoting ehuss replying to a very similar proposal which was brought forth by me in June '24:

You should be able to land the migration lint behind a feature gate instead of the edition gate. It normally should be a pretty trivial change when it is ready to be accepted in an edition to switch from if features().foo to if features().foo || span.edition().at_least_rust_20xx(), and to update the lint declaration's @future_incompatible field. That can be any time after it has been accepted, which can happen at any time before the edition ships (possibly years).

There's some documentation on doing this in https://rustc-dev-guide.rust-lang.org/guides/editions.html#lints-and-stability.

https://rust-lang.zulipchat.com/#narrow/channel/268952-edition/topic/Edition.20Beyond/near/442314182

[davidtwco]

I'm not sure that works in my case, I want to be able to enable the feature to refer to the unstable items it adds to the standard library and test those work with edition N behaviour, and then opt-in to the edition N+1 behaviour and test that.

I guess I could add multiple feature flags instead? But that just feels like it confirms there is a need for this but we just don't want to add it.

[ehuss]

Hm, I see. Would it be possible to call it something different, like "future"? We don't know what will actually go in the "next" edition, and thus I don't think it is good to make any presumptions about what will be bundled together. It would also be helpful to have a clear warning in the docs to not use the "future" edition unless you have a situation like this were you have two different unstable behaviors that you need to test across an edition boundary¹, that this edition marker is permanently unstable², and that any behavior must also be gated behind a feature gate³? Otherwise I'm concerned that people will actually use this edition marker, which will make testing and tracking difficult and lead to confusion about which edition something is targeted towards.

Would it also be possible to make the prelude changes doc(hidden), since it is permanently unstable?

Footnotes

1. Otherwise you should just use a regular feature gate. ↩

2. Once your feature has been accepted into an edition, the feature's code will need to be updated to check the appropriate edition number. ↩

3. That is, your could should always be tcx.features().my_feature && span.at_least_edition_future() ↩

[davidtwco]

Changed it to "future" and added requested descriptions.

[traviscross]

This sets something of a process around edition handling, so let's FCP this, which will also give us some time to think it through. On first impression, I had the same concerns as @ehuss. With the changes, it seems probably OK, so:

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @ehuss
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[traviscross]

@bors r=traviscross,ehuss rollup

[bors]

📌 Commit d6bb98e has been approved by traviscross,ehuss

It is now in the queue for this repository.

[riking]

There should be an RFC drafted that spells out the process around this, for example:

• The future edition has worse stability guarantees than nightly: it can not only be broken at any time due to API changes and removals, it can also contain syntax and semantics changes (e.g. when a Rust 2027 syntax change feature is enabled-by-default-in-edition, this means future gets that syntax change!)
• If work is landed in the future edition but it does not meet the edition quality bar (has completed migration lints, etc) when an edition cutoff occurs, the feature will remain in the future edition.

Started a Zulip topic: #edition>'future' edition policy RFC