Here’s a list of the unstable features used by the 100 most popular crates on crates.io (by reverse deps). Perhaps this query and others like it can help drive stabilization decisions.
30 crates report using some unstable feature. A number are just using the test feature, presumably only in the test suite, mostly for benchmarking it seems. Some also seem to be cfgd to optionally support nightly features.
These crates are popular because they work on stable, and maybe they don’t use some features that they would like to use because these features are unstable.
Not every crate writer has the motivation to add an unstable Cargo feature that enables more things.
The popularity is determined by the number of reverse dependencies each crate has, which can be calculated from the crates.io index.
More specifically, I first get the set of dependencies for every crate, discarding version numbers. So for every crate I have a map of its dependencies, from crate name to crate name. Then I do a simple sum of the direct reverse dependencies of every crate by walking over every crates dependencies.
Absolutely. Take it anyway it pleases you.
What I'm looking for is a simple metric that can be used to track the amount of nightly dependency, and also tools to help us decide what features to prioritize.
This seems like a good start to me. If we could e.g. make all these crates "green", that's better than today, where 30% are "red".
I'd love to hear suggestions for other techniques to track progress toward stabilization.
Note that some crates would like to use certain features that are presently unstable, but cannot because they must work on stable, nor can they provide a nightly cfg for it because it would be too major of an API change.
Like for winapi, I’d really like to use the new untagged unions, but I can’t yet. Making unions use that new feature would significantly change their API relative to the current hack, so a nightly cfg is out of the question.
Unstable features should be well tested before making them stable. So if the community don’t care enough to provide nightly builds for a crate using a specific feature, maybe that is a sign that this feature is not well tested yet, it is not mature enough to be stabilized.
Creating a separate version of your library that uses an unstable feature makes the code considerably more complex.
If you take features like the ? operator or break/continue being able to return a value for example, which are features that only affect the internals of your crate, it’s not worth making the code considerably more difficult to read just to use a feature that’s supposed to make the code slightly easier to read.
If you take features like -> impl Trait or ! being a proper type for example, which have an impact on a crate’s API, it’s too cumbersome to distribute two different versions of the crate with two different APIs and two different documentations. Nobody is going to use the unstable version anyway unless the gains are very substantial (which is the case for only very few features like plugins for example).
Interesting that try_from didn’t show up in this list. I use that in several of Ruma’s crates, and I feel like I’ve seen it a lot in other crates, though I can’t recall which offhand.
It's limited to the 100 most popular crates, so misses a lot. I'd rather see an aggregation of unstable features used across all crates, sorted by frequency of use.
I don’t think this is a good way to prioritize features. Basically it punishes people who put in extraordinary effort to make their crate work with the existing Stable Rust limitations (e.g. using C to implement things that can’t be done in Rust, or implementing other nasty workarounds). For example, I’d love to see const_fn in Stable Rust. Is the best way to do that to drop support for Stable in my crates and use const_fn now? That’s what this thread is encouraging, and it would make my code prettier (fewer macros in my code simulating const_fn).
Besides counting the crates that use a particular feature, we must also count the crates that don’t use a particular feature. 498 crates using the test feature seems like a lot until you consider there’s over 7,000 crates on crates.io, so 498 is less than 7%. This is the upper bound on the utility of such counting, and that bound is pretty low.
In the case of the test and bench stuff, IMO the fact that rustc-test crate exists means there’s really no work important to do right now, except for encouraging people to use rustc-test instead of the unstable built-in version. In other words, the most important-looking feature in the list isn’t really urgent, considering there’s a simple workaround.
Also keep in mind that people can only use feature flags for features that are already at least partially implemented. There’s no feature flag for #[repr(align)] or for guaranteed-constant-time integer operations, so those features aren’t counted at all. But there are really important features that haven’t even been started yet, which are (IMO) much more important than any of the ones listed.