Description
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
matchexpressions.
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 let | 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.
EDIT: A clarification: you can write if let A(x) | B(x) = expr { ... }. In other words, bindings do work.
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 RFC: Or patterns, i.e
Foo(Bar(x) | Baz(x))rfcs#2535. @varkor is currently working on an implementation for that generalization. -
let Ok(x) | Err(x) = expr;orfor 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.