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

Stabilization proposal for #![feature(if_while_or_patterns)] #56212

Open
Centril opened this Issue Nov 25, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@Centril
Contributor

Centril commented Nov 25, 2018

Stabilization proposal

I propose that we stabilize #![feature(if_while_or_patterns)].

Originally proposed in RFC rust-lang/rfcs#2175, then amended by rust-lang/rfcs#2530, implemented (partially, see below) in #48490 by @petrochenkov, and available in nightly since ~25th February, #![feature(if_while_or_patterns)] permits users to write multiple "or patterns" A(x) | B in if let, while let, for expressions and let statements.

See the motivation for an extended discussion; The primary reasons why this is useful are:

  • It permits more expressive and ergonomic control flow.

  • It is consistent with the behaviour of match expressions.

Version target

The next version is 1.32 which goes into beta the 7th of December; It is quite possible that this will slip into 1.33 however depending on how long the review process takes.

What is stabilized

Users are now permitted to write for example:

enum Thing { Alpha, Beta(u8), Gamma }

if let Thing::Alpha | Thing::Gamma = Thing::Gamma {
    ...
}

if let 0 | 1 = 0 { ... } else { ... }

let mut iter = make_thing_iter();
while | Thing::Beta(_) | Thing::Gamma = iter.next() {
    ...
}

Per rust-lang/rfcs#2530, leading vertical bars (|) are permitted; however, this behaviour cannot be observed on nightly right now. This is a fairly minor thing that will need to be fixed (+ test) in the stabilization PR.

What is not

Users are not yet permitted to write:

  • if let A(0 | 1) = expr { ... };

    This is the generalization of or-patterns as provided for by rust-lang/rfcs#2535. @varkor is currently working on an implementation for that generalization.

  • let Ok(x) | Err(x) = expr; or for Ok(x) | Err(x) in iter { ... }.
    This is provided for by the RFC but the implementation was more complex so this will be implemented in the future, possibly by @varkor in the generalization.

    This is a divergence from the RFC since a subset of the RFC is implemented.

@Centril

This comment has been minimized.

Contributor

Centril commented Nov 25, 2018

@rfcbot merge

Tracking issue is: #48215

@rfcbot

This comment has been minimized.

rfcbot commented Nov 25, 2018

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

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.

@joshtriplett

This comment has been minimized.

Member

joshtriplett commented Nov 25, 2018

@rfcbot concern subset-without-bindings

I feel like there's little point in stabilizing this without stabilizing bindings (the Ok/Err case). What's the urgency?

@Centril

This comment has been minimized.

Contributor

Centril commented Nov 25, 2018

@joshtriplett

There's not an urgency per se; it's just useful to have if let A | B = expr { ... } in stable Rust so that people can start using it; for example, there are places in the standard library where this would make code nicer. Targeting 1.32 is just because it's the closest nearby; if it slips to 1.33 then that's entirely fine, or we can, as @petrochenkov suggested, backport the stabilization PR to beta.

Wrt. the subset-without bindings, I had the same reaction as you, #48215 (comment); this was then discussed by @petrochenkov (#48215 (comment)), with me being unsure in #48215 (comment), and Niko noting finally in #48215 (comment) that piecemeal stabilization seems fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment