Stabilize feature(match_beginning_vert)

[goodmanjonathan]

With this feature stabilized, match expressions can optionally have a | at the beginning of each arm.

Reference PR: rust-lang-nursery/reference#231

Closes #44101

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @petrochenkov (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[petrochenkov]

@bors r+

[bors]

📌 Commit a99b5db has been approved by petrochenkov

[Mark-Simulacrum]

@bors rollup

[stepancheg]

RFC had 37 downvotes compared to 19 upvotes. Not obviously a good thing to be added to the language.

[warlord500]

I am very much against this being added to the language. it will lead to more confusing code!
looking at some of the code in Releases.md, i got mixed just looking at it

[pravic]

Same here. But nobody cares despite

The teams are required to take arguments against an RFC very seriously

[warlord500]

this will be the one feature I will hugely disagree with in rust! unless their is extremely (strong willed) segment of developers that do like this. every example, I have been able to look at Involving, I find more confusing than with out the leading vertical bar! Not only that, but I have to yet to find strong evidence of many people wanting this feature! yes, there could be an example, but to the best of my knowledge, (which to be honest Isnt a lot) most code with this syntax added leads to more confusing code!

[TomasHubelbauer]

For the record, while I don't have any idea how many people support this syntax, I do. I think F# uses vertical bars for match, too, and I personally am used to aligning union types this way in TypeScript, so it's welcome to have something familiar like this. Sure, the | symbol is also used for closures, but I believe the contexts are distinct enough for this not to matter.

[stepancheg]

The problem is not with the leading bar itself, the problem is that Rust now has two syntaxes to express the same thing. F# supports only leading bars. If Rust deprecated syntax without leading bars, that would probably be OK.

[tdbgamer]

Yeah all the arguments behind this RFC make no sense to me. There were alternatives that worked already and looked just as good. "I got used to it in F# and now I want it in Rust" is a bit of a strange argument to me. Rust shouldn't be some Frankenstein's monster of parts of different languages. Ideas should be evaluated based on their merit, and the value this brings to the table is very questionable to me.

As for all the people arguing for flexible syntax and allowing different styles... This is how languages like Perl happened. "There is more than one way to do it" isn't a good thing; it's confusing and fragments the language. To quote Tim Peters "There should be one-- and preferably only one --obvious way to do it."

Maybe this particular change is alright, but I just think a lot of the arguments made in this RFC are very dangerous and might lead Rust down the path many other failed languages have taken. Let's learn from their mistakes rather than repeat them because I really want Rust to succeed.

There should be very strong arguments before we bloat the language spec more with little changes that have very minimal benefit to users and just add more mental overhead for beginners.

[Gedweb]

Rust going to hell. We won't add C like increment, but this feature is OK. WAT?

[valeth]

This looks pretty useless to me, because you can't match (for me) obvious patterns like this:

let something = Some(1);
    
match something {
    | None
    | Some(x) => println!("something = {}", x)
};

Rust complains that the None pattern doesn't bind x.
It needs to be changed to this, which complete defeats the purpose of having the | in the first place.

let something = Some(1);
    
match something {
    | None    => (),
    | Some(x) => println!("something = {}", x)
};

Maybe I'm misunderstanding the feature, and there is a way to match such a pattern?

[H2CO3]

This is deeply worrying. Many users have expressed their concerns with this feature — they have been ignored and this feature, which adds more syntactic clutter, has been stabilized. Where did democracy go?

[liigo]

FWIW: RFC1925 was awarded the Most-Disliked RFC!

https://www.reddit.com/r/rust/comments/8ck0yv/rfc1925_is_awarded_the_mostdisliked_rfc/

[valeth]

Not really against having something similar to Haskell's guard statements.
But they need to at least have some practical use instead of just adding an optional syntax element that could easily be omitted.

[withoutboats]

@valeth no one ever seems to have answered your question, but your comment seems a bit confused about the scope of this stabilization. Rust has had the ability to match multiple patterns with a single arm since before 1.0. there's no way to do what you suggest in your post, because x would be uninitialized in the None case.

This change was strictly syntactical: it makes |pat|pat equivalent to pat|pat in the same way that a,b, is equivalent to a,b.

[Arcaelyx]

This seems like such a useless pattern to add if it provides no extra functionality. In the end, things like this lead to people wanting their own style thrown in to vastly complicate the language without providing any extra practical benefit. Such as:

If we are to throw this in, then why don't we have ternary operators as well?
At least that actually leads to more concise code as opposed to now having
useless bloat with no additional benefit.

Whereas the difference with this is that it at least provides some benefit, but we start spiraling out of control with adding in features like this.