RFC: Improve the visibility of the nightly compiler requirement for crates that use unstable features.

[jimmycuadra]

Rendered

[steffengy]

While the issue this tries to solve is a very obvious one,
this personally feels like the wrong approach to me.

Stabilization

• Crate uses feature XY, requires nightly.
• nightly=true is infered/set.
• Feature XY now is stabilized, but no new release of the crate is issued.

Therefore the crate would still be flagged as nightly, even though it now works on stable.

Another stabilization issue directly arises

• The author now removes nightly=true, someone on an older stable version still cannot use it,
  without getting any hint from crates.io.

Custom forks

In a corporate environment, forks of rust are possible.
Or simply the requirement to use a certain version due to regressions/BC-breaks.

So they are stuck on an older rust (nightly) version, where feature XY might not be available yet.
The nightly attribute only tells if the nightly that the author/CI used, works.

How can you determine if the features required by this crate are available for your specific rust nightly?

Conclusion

I personally feel that an approach based on version ranges based
on the features a crate uses would be a better solution.

E.g. showing on crates.io that Crate XY requires atleast Rust 1.19>=
based on the features that are being used by it.

Determining the features being used could be a bit more complicated, but is certainly possible:

• Detecting nightly features is easier since they are specified for each crate #![feature(XY)]
• Determining stabilized features is trickier, since you need to go over the code and check what features are being used (you cannot simply parse crate-metainformation).

[matthieu-m]

I am wary of cargo having to parse Rust code to detect the use of nightly features; is there a precedent for this?

Otherwise I would find it cleaner for the declaration of nightly features used to be in the Cargo.toml and for cargo to pass this information as flags to rustc, replacing the need for declaring said features in the source code itself.

Once the list is available in Cargo.toml, then it is relatively easy to check which compiler version is required for this to be stable on crates.io and indicate it as a tag. This tag would evolve in time whenever a new release of Rust occurs: for example, if the last feature requiring nightly on 1.19 is stabilised for 1.20, then the tag would move from nightly to 1.20+.

[steffengy]

@matthieu-m
I like the idea, since the requirement to parse rust code seems problematic.
But how does that work in regards to backwards-compatibility?

Surely one would need to keep #![feature[..]] around and deprecating it would seem wrong.

But how would you get people to actually specify the features in their cargo.toml?
You'd need a lint to notify users to use cargo's feature specification
insteadof #![feature(...)], when (and only when) they're using cargo and not rustc alone.

[carols10cents]

Related is this feature coming to crates.io Soon™: rust-lang/crates.io#764

[Ixrec]

Another issue the current RFC text doesn't address is crates that work fine on stable, but have optional cargo features that make use of unstable language features.

[choudanu4]

Ninja Edit: What @lxrec said. I didn't see his post.

=================================================================================
What happens in the case that a library has an optional dependency under a feature gate, and the optional dependency uses nightly features? Does the primary library receive the nightly badge?

As an example, tcod-rs used Serde's derive prior to Rust 1.15 stabilizing the feature. But, the library kept the feature under the #[cfg] feature gate "Serialization".

[aturon]

@carols10cents, since this is pretty related to your work on crates.io, I've assigned you to shepherd this RFC.

[carols10cents]

@jimmycuadra To move this RFC forward, it sounds like it could use amendments to address:

• Crates that have optional dependencies on nightly features behind a feature gate
• What happens if a feature is stabilized but a new version of the crate hasn't been released

Do you have any thoughts on how to address these issues?

[jimmycuadra]

I've got some ideas about how to revise my proposal based on the feedback so far. I should be able to get to it soon. Everyone can hold off until I update the text. Thanks!

[jimmycuadra]

I'm closing this until I have time to address feedback. I don't want to waste anyone's time. :}