Allow external crate to use unnecessary #[feature] on stable

[newpavlov]

I was proposing something similar in this thread:

Idea: Semi-stabilization

Summary 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 wil…

One of the concerns was adding notion of features to stable lang, this is why one of the alternatives developed during discussion was to move enabling of features to Cargo.toml.

[Ixrec]

@CAD97

The problem as I see it is around features that are both

1. stable enough that it was used and stabilized in the same form,
2. useful enough that they were used rather than a stable-compatible shim, and
3. old enough that libraries that used them in development are no longer in active development (otherwise they’d just remove the flag)

so this leads me to believe that some sort of “semi-stable” feature flag would be the proper response to this, for features that are likely to fall into the above case.

My reaction to this case is that, if the feature went through no significant changes for that long, then either it should've been stabilized a while ago, or it's fallen into some kind of "limbo" status.

So maybe this is all just a symptom of us having too many feature flags in limbo status, and the proper solution is instead addressing things like "organizational debt" and the backlog of almost-but-not-quite-finished features, which are already explicit parts of our roadmap.

[Centril]

@H2CO3

I’m not sure what you mean by that, but if you can (on nightly) use a #![feature] , then it most certainly is implemented.

(This isn't true anymore; we have INCOMPLETE_FEATURES for the things that aren't (but we also emit a lint for such features so you will know when you use them).)

@KSXGitHub

This could have been avoided if feature has semantic versioning. Like so:

#![feature(foo@2.0.0)]

I think this adds hugely to the complexity and burden of being a compiler developer since you have to bump the version everytime you do a subtle "breaking" change. I'm not willing to add this burden to an already overburdened compiler team.

@CAD97

There’s also been some mention of removing old feature names from the compiler as a form of cleaning. This would be impossible if stabilized feature names are whitelisted on stable. cc @Centril, haven’t you argued this position before?

Yes, as I see it, feature_gate.rs + symbol.rs are monotonically adding garbage with the current situation.

Stabilizing the feature system not only stabilizes names (worse if you have some sort of #[cfg(rust_feature = "my_feature")] in which case you cannot ever garbage collect), as @petrochenkov notes we can still probably garbage collect with #![feature(foo)] but it forces a particular mode of language development using feature gates on rustc and alternative Rust compiler.

@Ixrec

So maybe this is all just a symptom of us having too many feature flags in limbo status, and the proper solution is instead addressing things like “organizational debt” and the backlog of almost-but-not-quite-finished features, which are already explicit parts of our roadmap.

---

If we insist on supporting situations like this, then #[cfg(accessible(::std::foo::bar))] + #[cfg_attr(feature = "unstable", feature(feature_that_provides_foo_bar))] seems cleaner.

[mcy]

@CAD97

The biggest argument against is that this would stabilize the feature names as part of the language when they’re meant to not have any meaning and were picked arbitrarily.

I'd like to observe that this need not be true- there is certainly no reason that we can't make the behavior of #![feature("..")] implementation-defined and non-portable. I argue that this is the current behavior, wherein stable completely bans it, and nightly changes its behavior on a small whitelist of values.

See Implementation defined behavior control - cppreference.com

[troplin]

Couldn’t the stable compiler just simply ignore any #![feature(..)] pragmas?

[tspiteri]

I think this should not be a feature of the Rust language, that is it would be really weird to have a page in the Rust language reference saying that you can write #![feature(repr_transparent)] at the top of your crate.

If anything, it could be a convenience feature of rustc itself where some recently stabilized features only emit a warning instead of an error, where recently could mean during the last two or four or eight versions, or maybe even more, but still a limited period.

[Ixrec]

@tspiteri

If anything, it could be a convenience feature of rustc itself where some recently stabilized features only emit a warning instead of an error, where recently could mean during the last two or four or eight versions, or maybe even more, but still a limited period.

I think I would find this compelling if there were multiple Rust compilers and every "serious" project was expected to run at least two of them in their CI, like in the C++ world. But for better or worse, that's not a thing yet, so anything that rustc deems a non-error on stable today simply is de facto standardized forever.

[gbutler]

Personally, I find the near constant calls to allow “Unstable” things on “Stable” to be a complete contradiction. Either you are targeting stable or you are experimenting with unstable features on nightly. Never the two shall meet.

If a library you want to use is unstable, and you want to target stable, you simply cannot use that library, FULL STOP. If a library remains on nightly just because no one has updated it to use the stable features (and remove references to the unstable “feature” flag), then there are two and ONLY two solutions:

• Get the maintainers to fix the library
• Fork the library and make a stable version

That’s it. That’s the fix. Please, DO NOT COMPROMISE on this. DO NOT mix unstable/nightly into the stable branch in some sort of frankenstein-like, chimeric disaster.

[withoutboats]

No one in this thread is proposing to make unstable features accessible on stable. This post uses a very dramatic register while significantly misunderstanding the discussion. I find this frustrating and disappointing.

[KSXGitHub]

@gbutler

• Fork the library and make a stable version

What if I don't depend on that library directly? Instead, the library I use uses no #[feature] flag but depends on another library that uses one.

@gbutler

• Get the maintainers to fix the library

This is very unproductive. I first have to make an issue, then I have to wait for the secondary dependency to resolve my request, and then my direct dependency to update the secondary dependency, only then shall I be able to continue normally.

[CAD97]

@KSXGitHub

and then my direct dependency to update the secondary dependency

If it is "just allow #[feature]", then only that library needs an update: it's a semver-patch level change, and then a cargo update to recalculate your lock will pick the new version.

And a crate depending on a crate which is nightly-only is nightly-only as well, it's transitive.

To those who want this kind of feature for rustc: what feature flags would you have benefitted from having this, and what libraries did they reside in? I'd posit any feature that is both stable and old enough to hurt here probably should have been stabilized already, and the correct direction is to push for the stabilization or removal of these older, "almost finished" features before forward-stable-compatibility of using them.

[ahmedcharles]

I think his post understands the situation precisely and it actually reflects my understanding and opinion. Stating whether you’re frustrated or not doesn’t seem to add to the discussion.

[burntsushi]

Moderation note: Let’s please increase the quality of discussion here. It is veering into unproductive territory. If it doesn’t improve, then we’re just going to lock the thread.

[mjbshaw]

I think part of the problem with allowing #[feature] on stable (for features that are already stabilized) is that it’s not clear that the crate intends to support stable Rust just yet. Any crate that is using #[feature] is targeting nightly (and any crate that depends on such crate is also targeting nightly, by necessity).

If #[feature(foo)] gets stabilized and #[feature(foo)] is permitted on stable, it might give the false impression that the crate supports stable Rust. But that’s not necessarily the case. The crate might target only nightly (even if it’s only using stable features) because it wants to use an upcoming unstable feature. If the crate then adds #[feature(bar)] (where bar is unstable), all stable Rust users of the crate will break.

This is why I’m personally opposed to using #[feature] on stable. I think it’s best to fix the upstream crate, which will give the crate authors the opportunity to reject stable Rust if they’re intentionally targeting nightly Rust and don’t want to give the false impression of stability.

[yarrow]

This has me convinced:

@mjbshaw

If #[feature(foo)] gets stabilized and #[feature(foo)] is permitted on stable, it might give the false impression that the crate supports stable Rust.

Switching from stable to nightly is (at least!) equivalent to a semver major version bump. So letting nightly crates more-or-less accidentally work on stable means that authors of nightly crates would have the surprising duty, before releasing a new minor version, of making sure either that the old version didn't work on stable, or that the new version does. And that applies to every nightly crate, not just old unmaintained crates.

Bump the major version number for the bug fix that happens to start using an unstable feature, or face the wrath of your users! Your stable users, that you didn't want in the first place.

[rubberduck203]

@KSXGitHub

What if I don’t depend on that library directly? Instead, the library I use uses no #[feature] flag but depends on another library that uses one.

Then the library isn’t stable because it has dependencies that aren’t stable.

@KSXGitHub

I first have to make an issue, then I have to wait for the secondary dependency to resolve my request, and then my direct dependency to update the secondary dependency, only then shall I be able to continue normally.

As a long time open source maintainer, I’ll give you the advice that I gave to every user who opened an issue on our repository. The fastest way to see a change made is to do the work and submit a pull request. Most of us building OOS do it as a hobby in our spare time. We always appreciate contributions. Yes, you may need to point your actual project at your fork for a minute until the maintainer can merge your PR and publish a new release, but it gives you a path forward and the library gets a needed update. That’s a win for everyone involved. That’s how open source is supposed to work, and in my humble opinion, is the right solution to this problem. Not all problems require technical solutions. Some just require people working together to make the community a better place for everyone.

[gbutler]

@rubberduck203

That’s a win for everyone involved. That’s how open source is supposed to work, and in my humble opinion, is the right solution to this problem. Not all problems require technical solutions. Some just require people working together to make the community a better place for everyone.

This deserves to be the "Quote of the Week" IMHO!

[withoutboats]

This is actually a very fair concern that probably tips the scales. To reiterate it in other language: right now, if you already use the feature attribute, it is considered fair game to only support the latest nightly. This means its not a breaking change to add dependencies on additional features. But if that could spill over into supporting some stable versions, you would be breaking those users.

This could lead to more surprise broken builds, which are worse than crates that don’t compile on stable for no reason, because they impact users at unexpected times.