Unstable features accidentally usable on the Stable release chanel are still unstable #2405
Conversation
|
CC @rust-lang/libs |
withoutboats
added
the
T-core
|
assigning to core team because its about project-wide policy |
|
Kicking off core team review: @rfcbot fcp merge |
rfcbot
added
the
proposed-final-comment-period
|
Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:
No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
| @@ -22,6 +22,10 @@ The RFC covers only API issues; other issues related to language features, | |||
| lints, type inference, command line arguments, Cargo, and so on are considered | |||
| out of scope. | |||
|
|
|||
| The stability promise specifically does *not* apply to unstable features, | |||
| even if they are accidentally usable on the Stable release channel | |||
| under certain conditions such as because of bugs in the compiler. | |||
There was a problem hiding this comment.
Hmm; Maybe say 1-2 words about who decides this? (I assume the responsible team does?)
There was a problem hiding this comment.
This PR is intended to be the decision?
There was a problem hiding this comment.
What I mean is: if we in the future find new "bugs" wrt. unstable; who decides if it was really a bug, or working as intended? I guess the criteria for bug could be / is that something became stable without going through a stabilization FCP?
There was a problem hiding this comment.
In the standard library at least I think there’s no ambiguity since every public item is required to have either #[stable] or #[unstable]. Though you’re right that it’s may not that clear cut for language features.
There was a problem hiding this comment.
Small note re. standard library: trait impls are insta-stable regardless of #[unstable] afaik and macros do not respect stability attributes either.
| @@ -22,6 +22,10 @@ The RFC covers only API issues; other issues related to language features, | |||
| lints, type inference, command line arguments, Cargo, and so on are considered | |||
| out of scope. | |||
|
|
|||
| The stability promise specifically does *not* apply to unstable features, | |||
| even if they are accidentally usable on the Stable release channel | |||
There was a problem hiding this comment.
Could we remove the accidentally wording here? Things like the bootstrap environment variable aren't accidental, but we still don't consider them stable.
|
Ping @rust-lang/core, @SimonSapin Any progress here? |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
rfcbot
added
finished-final-comment-period
Centril
added
the
A-stability
In some cases, it is possible to use unstable features on the Stable release channel. For example:
foo::bar::bazpath is checked for stability: Track stability of path components rust#15702. (See for example Add inherent methods in libcore for [T], [u8], str, f32, and f64 rust#49896 (comment).)testor with some other name of a standard library crate, is it possible to override what is called by some compiler-generated code. Things break when the signature of those calls later change: Regression in 1.26: cannot find functionassert_test_resultin moduleself::testrust#49942This PR proposes that the semantic versioning / stability promise normally associated to the Stable release channel specifically do not extend to such cases. Finding a way to bypass the stability system should not be sufficient to make unstable features de-facto stable.