RFC: Or patterns, i.e Foo(Bar(x) | Baz(x))

[Centril]

🖼️ Rendered

⏭ Tracking issue

📝 Summary

Allow | to be arbitrarily nested within a pattern such that Some(A(0) | B(1 | 2)) becomes a valid pattern.

💖 Thanks

To @Nemo157 and @joshtriplett for reviewing the draft version of this RFC.

[joshtriplett]

👍 I've wanted this for a while, and I look forward to using it.

[ghost]

I think a drawback is that it may be suprising with bitwise or

let x = Some(1 | 2);
match x {
    Some(1 | 2) => (), // won't happen, but intuition says it would
    _ => panic!()
}

... But I guess that it's kind of already an issue right now anyway

let x = 1 | 2;
match x {
    1 | 2 => (), // won't happen
    _ => panic!()
}

[joshtriplett]

@whataloadofwhat Yeah, | already doesn't mean bitwise or in the context of patterns.

[scottmcm]

nit: pat ::= "|"? pat "|" pat; is definitely bad, since it would allow patterns like | | A | B | C via the interpretation | (| A | B) | C. So I'm absolutely in favour of the current plan.

[SimonSapin]

+1 on the general goal.

What is the impact on pat fragment in macro_rules? Unlike other some other combinations forbidden by RFC 550 Macro future-proofing, | is allowed to follow a pattern today and this runs without asserting in Rust 1.28.0:

macro_rules! foo {
    ($a: pat) => { false };
    ($a: pat | $b: pat) => { true };
}

fn main() {
    assert!(foo!(Some(_) | None));
}

[SimonSapin]

RFC 550’s "Edit history" section links to #1336.

[mark-i-m]

We can and have disallowed some characters in macros before (e.g. ? in separators), but we would need to act fast.

[SimonSapin]

“Fast” as in before May 2015?

[durka]

Was serious consideration given to avoiding breakage by requiring parentheses when doing alternation at the top level? It was not added to the alternatives or drawbacks section... and this isn't the first RFC to ignore/dismiss macro breakage. Other than that I strongly approve.

[Centril]

@durka

It was not added to the alternatives or drawbacks section.

It wasn't added to the alternatives because it is the proposal ;)

Finally, pat macro fragment specifiers will also match the pat<no_top_alt> production as opposed to pat<allow_top_alt>.

[durka]

Oh, okay great! That should be in the guide-level docs as well, not just buried in the grammar definition.

[rfcbot]

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

[Centril]

Huzzah! This RFC has been merged!

Tracking issue: rust-lang/rust#54883

[mortarroad]

I think a drawback is that it may be suprising with bitwise or

let x = Some(1 | 2);
match x {
    Some(1 | 2) => (), // won't happen, but intuition says it would
    _ => panic!()
}

... But I guess that it's kind of already an issue right now anyway

let x = 1 | 2;
match x {
    1 | 2 => (), // won't happen
    _ => panic!()
}

I agree, and I think it's horrible. I read the release notes today, and especially the example there reads highly ambiguously:

// Before
matches!(x, Some(1) | Some(2));
// Now
matches!(x, Some(1 | 2));

It may have been ambiguous before, but now it is way worse. I'm expecting this to cause a bug or two down the line.
This is a terrible sugary addition to a language that is designed for writing robust code (we have mandatory curly braces!).
I'm kind of expecting this to be a lint for integers soon...

I don't have many issues with Rust's design, but this is just plain awful.

[RalfJung]

There are many situations where the new syntax makes writing robust code a lot easier since it avoids tons of repetition. It is already used plenty of times inside the Rust compiler, for example.

But I agree that in the very special case of integer patterns, this is not great. Note however that the issue exists before this RFC already, so it's not really a problem introduced by the new syntax (even though it might be amplified). Would you like to open an issue describing the problem and possible solutions? (Discussions on merged RFCs are not going to lead anywhere, and are probably just going to get lost.)

[SimonSapin]

Some confusion is possible at a glance, but pattern context v.s. expression context is enough to resolve it. Most expression operators are syntax errors in patterns. For example matches!(x, Some(1 + 2)) is a syntax error, it is not equivalent to matches!(x, Some(3)).

[mark-i-m]

A lint for the specific case that @mortarroad pointed out seems like a good idea. Frankly, it never occurred to me that one might use a bitwise or in that context (and I do a lot of bit-twiddling). Personally, I find that nested or-patterns are major ergonomics improvement, especially when right something like a state machine.