Tracking issue for RFC #2175: or-patterns in if / while let expressions

[aturon]

This is a tracking issue for the RFC "or-patterns in if / while let expressions" (rust-lang/rfcs#2175).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (Stabilize #![feature(if_while_or_patterns)] #57532)
• Stabilization PR (Stabilize #![feature(if_while_or_patterns)] #57532)

[zackmdavis]

This seems likely to be a rather straightforward change: currently parse_arm calls parse_pats to parse the |-separated patterns of a match arm, whereas parse_if_let_expr just calls parse_pat.

I'd like to take this.

[zackmdavis]

Arguably we should retitle the issue and RFC to make it clear that the ultimately approved proposal actually includes let itself (in addition to if let and while let).

[zackmdavis]

This seems likely to be a rather straightforward change: currently [...]

Er, this remark was terribly naïve: the change to the parser might be that simple, but then the IfLet (&c.) AST nodes have to hold a vector rather than a single pattern, and much of the code that handles them (e.g., HIR lowering) needs to change correspondingly.

[nikomatsakis]

@zackmdavis

Er, this remark was terribly naïve: the change to the parser might be that simple, but then the IfLet (&c.) AST nodes have to hold a vector rather than a single pattern, and much of the code that handles them (e.g., HIR lowering) needs to change correspondingly.

Sounds about right. but it should still be something that can be done purely in HIR lowering, right? I would think so.

[zackmdavis]

something that can be done purely in HIR lowering, right?

Visitors, pretty-printing, and resolution are also affected.

[nikomatsakis]

Sounds about right. I guess what I meant is "after HIR lowering, I wouldn't expect much other code to care"

[zackmdavis]

(I was actively working on this today, but would seem to have been pre-empted by #48490.)

[dtolnay]

Does optional leading vert need to be supported here for consistency with #44101?

if let
    | A(x)
    | B(x) = expr
{
    /* ... */
}

@mdinger

[mdinger]

@dtolnay

I would argue yes because examining a large number of cases in that fashion would be advantageous over non-prepended verts (assuming you prefer the style). Maintaining consistency with match definitely is a benefit.

Additionally, I wouldn't expect many downsides to this. The main ones would be a complexity increase, dislike from people who disapprove of the style, and perhaps macro particulars being more complicated.

[mdinger]

Also, the RFC grammar should be updated to reflect this change.

[Centril]

I concur with @mdinger, the intention of the RFC was to increase uniformity and consistency.

[Centril]

@petrochenkov The let Ok(x) | Err(x) = foo; part has not been implemented yet, right?

[petrochenkov]

@Centril
No, | in if let and while let is simple desugaring, but | in let is pretty much equivalent to full rust-lang/rfcs#1882 as I understand it.

Does optional leading vert need to be supported here for consistency with #44101?

I didn't implement it only because it required an extra flag in AST for feature gating, now leading | is stable so it can be added trivially.

[Centril]

@petrochenkov So I forgot to say that | in let is only permitted at the top level with the RFC as written; it does not amount to full rust-lang/rfcs#1882, so the following would still be illegal with this RFC:

let (None | Some(_), None | Some(_)) = (None, None);

[alexreg]

@Centril 😞 Still, better than nothing!

[Centril]

Update: rust-lang/rfcs#2530 was accepted to extend this RFC to for loops and optional leading vert.

[Centril]

I'm closing this issue in favor of #54883 to track all those changes since rust-lang/rfcs#2535 subsumes RFC 2175.

[petrochenkov]

Reopening because the implemented feature if_while_or_patterns still points to this issue.
Nothing prevents passing this subset through stabilization before the larger #54883 is implemented.

[petrochenkov]

@Centril
Could you start an FCP for stabilization?

The feature was implemented in #48490 as trivial desugaring into match, that PR also has tests.

[Centril]

@petrochenkov the let Ok(x) | Err(x) bits and the changes in rust-lang/rfcs#2530 are not implemented as far as I know, both of which are part of RFC 2175 + amendment.

[petrochenkov]

@Centril
As I said in one of the previous comments, let Ok(x) | Err(x) is a complex feature equivalent to full #54883, and the leading vert can be added in the stabilization PR or later, it's not a blocker/back-compat concern.

My goal here is to stabilize this occasionally useful feature now, and not delay its stabilization on larger implementation work required to support its extensions.

[Centril]

@petrochenkov being the new kid on the lang team block, I'm unsure as to whether we are OK with stabilizing parts of RFCs or whether we require them to come in units... In particular, @nikomatsakis noted in RFC 2175 that let Ok(x) | Err(x) = ... was a requirement to accept 2175... But the team is in agreement to go much further; so I don't know. I will defer to Niko here (or someone who has been in @rust-lang/lang longer than me...).

[nikomatsakis]

I think it's fine to stabilize part of an RFC, we do it all the time. What I would recommend is that we open up a new issue dedicated to the stabilization (this is what we should always do, in my opinion). The issue header can describe clearly :

• What behavior is being stabilized
• How this deviates from the RFC (it it does)
• What unresolved questions are being resolved through this stabilization
• What behavior is NOT being stabilized
  • and why
• Test cases for all of the above

A good example where we did this "staged stabilization" was for the ? in main RFC. If you check out the tracking issue #43301 you will see that it has a section called "Stabilizations", which lists two sub-issues:

• Stabilize main with non-() return types (Stabilize main with non-() return types #48453) Merged in Stabilize termination_trait, split out termination_trait_test #49162
• Stabilize unit tests with non-() return types (Stabilize unit tests with non-() return type #48854)

Those issues are examples of the kind of report I would like to see (I did them myself, so asking for anything more would be somewhat hypocritical I suppose :)

[Centril]

@petrochenkov could you write up a report per #48215 (comment) in a new issue (or PR at your option...)? I'll fcp merge that :) I'd like the stabilization PR to include leading vert at least also.

[petrochenkov]

Ok, will do.

[Centril]

Proposed in #48215.

[glaebhoerl]

@Centril You mean #56212 😛

[Centril]

@glaebhoerl hihi =P // blames copy buffer

[Centril]

Stabilization happened in #57532.
Documentation issue: rust-lang/reference#505

The remaining work is tracked in #54883.