Proposal: make a "nightly" edition

[CAD97]

(Warning: approximately quarter-baked idea)

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:

1. Make edition = "nightly" required to opt in to #[feature]
2. Make edition = "nightly" opt in to the “code-complete” features expected to headline the next edition
3. 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

[gbutler]

I think this idea might be a little easier to understand if you could provide some specific use-cases.

[kennytm]

Nightly features can often be configured by cargo features, e.g. the regex crate has

#![cfg_attr(feature = "pattern", feature(pattern))]
#![cfg_attr(feature = "unstable", feature(target_feature, stdsimd))]

How could edition = "nightly" cope with this?

[cuviper]

Nightly features can often be configured by cargo features, […] How could edition = "nightly" cope with this?

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.

[newpavlov]

I do not think that we should use edition for it, but the rust (or rustc) flag from minimum Rust version proposals.

[scottmcm]

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.

[daboross]

How could we handle testing nightly features in older editions, then?

Since most new features will be available in all rust editions, do we want to restrict people testing nightly features to the latest edition?

[scottmcm]

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.

[CAD97]

† 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 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

[Ixrec]

#![feature(bleeding_edge)]

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.

[scottmcm]

#![feature(edition_2018_preview)] enables all unstable features likely to headline Edition 2018!

Looks like this is in the plan already:

Issue: Make epoch features get enabled by #![feature(rust_2018_preview)]

[CAD97]

(I mentioned this idea on GitHub on an epoch issue just before but missed the new one, thanks!)

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.