Now that the Rust edition is a fully formed concept, would it make sense to “promote” nightly to a full edition?
There are three ways I think that could be handled:
Make edition = "nightly" required to opt in to #[feature]
Make edition = "nightly" opt in to the “code-complete” features expected to headline the next edition
Make edition = "nightly" opt in to any RFC-approved “code-complete” features
I think the nightly toolchain should still be required for nightly features (sounds obvious now that I said it), so the first option seems redundant. The second is great, especially in the lead-up to stabilization of key edition features for easy opt-in, but could also be accomplished by just letting nightly users specify a future edition. The third is the most generally applicable.
What do you think? I’ve currently got a header block enabling all of the feature gates tracked in the Epoch.Next tracking issue for my personal-for-fun projects, so I know I’d use the “nightly edition” for those at least.
Benefits
Easier to try out solid(ish) upcoming features without knowing the state of every feature gate
And thus easier to get feedback on features nearing stabilization
Drawbacks
Makes there two places to look for nightly feature enabling (main.rs + Cargo.toml) instead of just one
Though silently using things stable on a later compiler version than you thought you supported is still a problem – CI your things please
Makes it easier to exit Rust’s careful stability story
Adds an unstable edition to a versioning scheme that’s supposed to highlight the stability of the Rust compiler
We can already write [target.cfg(...).dependencies] in Cargo.toml, although I'm not sure if features work in there. But maybe we could enable other stuff under [target.cfg(...)] too.
I wonder if edition = "nightly" could turn on all† the features as a way to address things like https://github.com/rust-lang/rust/issues/43302#issuecomment-372069505 by having some builder on the most bleeding of bleeding edges. Or just for people doing little one-off experiments that don’t really care about the fact they’re using unstable things and don’t get any value from adding a bunch of [feature]s. (crates.io might want to block crates for such an edition, though.)
† Where “all” is probably not really “all”, but more like “ones that we think have a reasonable chance of being stabilized in roughly their current form”, which would be a good list to have anyway.
I think that would only be the case in (1), which I agree is too strong. But I also wouldn’t be surprised if a number of (non-library) features ended up only existing on the latest edition (at the time of their stabilization, and of course those after it) to help simplify the understandability and testing matrices.
I think this is roughly equivalent to what I originally had in mind.
Thus,
Counter-Proposal: Feature groups
Like existing warning groups, add feature groups to allow un-gating multiple features at the same time.
Guide-level
#![feature(edition_2018_preview)] enables all unstable features likely to headline Edition 2018! #![feature(bleeding_edge)] enables features likely to be stabilized in a form similar to its current state.
Benefits
Ease of seeing the future by enabling a group of features at one time
Enables easier testing (thus likely more wide-spread) of likely-to-be-stabilized features by grouping them
It'd be cool to get rustc using #![feature(bleeding_edge)] instead of whatever amount of feature ungating it does currently
Drawbacks
Code with #![feature(bleeding_edge)] is even more likely to break than current code with #[feature] as features are added and removed from the group
Obscures further the features a project relies on and ties it even more to a specific nightly
I really like this idea, with one small tweak: Maybe cargo should not allow you to publish anything to crates.io with hyper-unstable feature groups like this, until you replace it with more specific #![feature()]s.