Skip to content

RFC: Un-feature-gate if let and tuple indexing #450

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

Merged
merged 2 commits into from
Dec 2, 2014
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 56 additions & 0 deletions text/0000-un-feature-gate-some-more-gates.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
- Start Date: (fill me in with today's date, YYYY-MM-DD)
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

Remove the `tuple_indexing`, `if_let`, and `while_let` feature gates and add
them to the language.

# Motivation

## Tuple Indexing

This feature has proven to be quite useful for tuples and struct variants, and
it allows for the removal of some unnecessary tuple accessing traits in the
standard library (TupleN).

The implementation has also proven to be quite solid with very few reported
internal compiler errors related to this feature.

## `if let` and `while let`

This feature has also proven to be quite useful over time. Many projects are now
leveraging these feature gates which is a testament to their usefulness.

Additionally, the implementation has also proven to be quite solid with very
few reported internal compiler errors related to this feature.

# Detailed design

* Remove the `if_let`, `while_let`, and `tuple_indexing` feature gates.
* Add these features to the language (do not require a feature gate to use them).
* Deprecate the `TupleN` traits in `std::tuple`.

# Drawbacks

Adding features to the language this late in the game is always somewhat of a
risky business. These features, while having baked for a few weeks, haven't had
much time to bake in the grand scheme of the language. These are both backwards
compatible to accept, and it could be argued that this could be done later
rather than sooner.

In general, the major drawbacks of this RFC are the scheduling risks and
"feature bloat" worries. This RFC, however, is quite easy to implement (reducing
schedule risk) and concerns two fairly minor features which are unambiguously
nice to have.

# Alternatives

* Instead of un-feature-gating before 1.0, these features could be released
after 1.0 (if at all). The `TupleN` traits would then be required to be
deprecated for the entire 1.0 release cycle.

# Unresolved questions

None at the moment.