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.

[whataloadofwhat]

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?

[scottmcm]

Do coercions apply, or do they need to unify exactly?

[Centril]

Summary from Discord conversation:

...So according to the coercion rules, if match is a coercion site, then the following should work according to the type coercion rules:

fn main() {
    enum E<'a> {
        A(&'a u8),
        B(&'a mut u8),
    }

    match unimplemented!() {
        E::A(x) | E::B(x) => {
            let x: &u8 = x;
        }
    }
}

However; match is not coercion site, so possibly the coercions would apply for let.
For now, I think we can be conservative and require an exact match and relax it later if need be / it makes sense.

In relation to type ascription, one could reasonably expect that E::A(x : τ) | E::B(x: τ) should work if x on both sides are implicitly coercible to τ but I don't think we need to specify that interaction just yet.

[Centril]

Amended the RFC with a clarification according to the above notes.

[eddyb]

match wouldn't be the coercion site here, the individual patterns would need to be. Currently, the x binding there is the same variable (initialized on two possible disjoint execution paths), and can't possibly have two types (but we can relax that in the future).

[rfcbot]

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

[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