In addition to stable and unstable feature statuses introduce an additional “semi-stable” status. While technically it will be equivalent to unstable, the responsible team announces that feature in question is ready for stabilization and no breaking changes are planned, so all interested parties are welcomed to use the feature and even publish crates which use it. In other words, while it’s possible that breaking changes will be introduced to semi-stable feature (e.g. if serious flaw will be found), the team ensures that probability of such event is assumed very low.
#[feature(stable_feature)] a warning, instead of compile error. This will allow crate developers to publish crates which depend on nightly, but with high probability that they will work on future Rust stable version without any changes.
Since fundamental crates like
diesel started to work on stable Rust, we can see more and more signs of Nightly “demonization”. Many users perceive nightly features as highly unstable and unsuited for investing their resources into using them. This in turn not only significantly reduces amount of experimentation which feature undergoes before stabilization, but also applies serious pressure on Rust teams to stabilize features (especially high-profile ones). The most notable example is pursuit to stabilize async/await (including parts of it like
Pin) while most of async code (seemingly) continues to use
futures v0.1, with
tokio being a flagship here. See the following threads for more context:
Also some stabilization RFCs argue that feature should be stabilized for it to be used more extensively, e.g. RFC 2480:
But publishing a library that uses unstable features, even optionally, comes with the expectation that it will be promptly updated whenever those features change. Some maintainers are not willing to commit to this.
I believe this trend is quite dangerous and seriously undermines Nightly experimentation model, which can be really harmful in the long-term.
Introduce semi-stabilized feature status. While this status will not add any technical guarantees over unstable status, it will provide informal indication that feature is ready for usage and it’s on path to stabilization.
The easiest way of implementing this proposal will be to simply mark tracking issues with an additional tag and doing an announcement in TWiR.
A more involved approach will be to introduce
#[semistable("feature_name", issue="N", version="1")] attribute. Note the
version field, while enabling semi-stable feature you’ll be able to provide version value (i.e. instead of
#![feature("feature_name")] you will use
#![feature("feature_name", version="1")]). In rare cases of breaking semi-stable feature the version number will change, thus instead of getting confusing compiler errors users will get a human readable error, which will notify them about a breaking change.
Additionally to promote usage of semi-stable features across ecosystem we could make
#![feature("stabilized_feature", version="..")] a warning instead of an error on stable Rust (assuming feature got stabilized with the same version number). This way crate authors will be able to publish crates which use semi-stable features and which will work on future stable Rust version. For example
tokio will be able to publish v0.2 which will use std futures and if no serious flaws will be found,
tokio v0.2 will work on future stable Rust without any additional changes.
Another way to promote use of semi-stable features is to create an informal rule: after feature was semi-stabilized it will be automatically fully stabilized in ~3 releases if no serious flaws were detected. And if we want to be more conservative we could even require semi-stabilization step for every feature.
Yes, there is a small risk that crate authors will have to bear maintenance burden if breaking changes will be introduced to semi-stable feature, but I believe it’s a much smaller price to pay than risk of stabilizing a flawed feature.
P.S.: Reddit discussion of this proposal can be found here.