Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unstable features accidentally usable on the Stable release chanel are still unstable #2405

Merged
merged 1 commit into from
May 31, 2018

Conversation

SimonSapin
Copy link
Contributor

@SimonSapin SimonSapin commented Apr 17, 2018

In some cases, it is possible to use unstable features on the Stable release channel. For example:

This 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.

@SimonSapin
Copy link
Contributor Author

CC @rust-lang/libs

@withoutboats withoutboats added the T-core Relevant to the core team, which will review and decide on the RFC. label Apr 17, 2018
@withoutboats
Copy link
Contributor

assigning to core team because its about project-wide policy

@aturon
Copy link
Member

aturon commented Apr 18, 2018

Kicking off core team review:

@rfcbot fcp merge

@rfcbot rfcbot added the proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. label Apr 18, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented Apr 18, 2018

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm; Maybe say 1-2 words about who decides this? (I assume the responsible team does?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is intended to be the decision?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we remove the accidentally wording here? Things like the bootstrap environment variable aren't accidental, but we still don't consider them stable.

@Centril
Copy link
Contributor

Centril commented May 5, 2018

Ping @rust-lang/core, @SimonSapin Any progress here?

@rfcbot
Copy link
Collaborator

rfcbot commented May 21, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels May 21, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented May 31, 2018

The final comment period, with a disposition to merge, as per the review above, is now complete.

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this RFC. and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels May 31, 2018
@Centril Centril merged commit 51e3cbc into rust-lang:master May 31, 2018
@SimonSapin SimonSapin deleted the unstable-means-unstable branch June 23, 2018 01:30
@Centril Centril added the A-stability Proposals relating to policy and changes about stability of features. label Nov 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-stability Proposals relating to policy and changes about stability of features. finished-final-comment-period The final comment period is finished for this RFC. T-core Relevant to the core team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants