Disagreement over optional match vertical

community
1

In a new release for rust, there is a RFC called
1925-optional-match-vert.md.
while, many might not care about this change! I do!

I hope that being creating a post like this, I will be able to create an rfc that will get accepted to reverse this change before it cant be reversed!
for those, who cant bother to read the rfc, it make vertical bar optional in the front of match branch!
makes this code compile
enum Foo { A, B, C }

fn main() {
  let x = Foo::A;
 match x {
      | Foo::A
      | Foo::B => println!("AB"),
      | Foo::C => println!("C"),
   }
}

like this code

enum Foo { A, B, C }

fn main() {
  let x = Foo::A;
 match x {
      Foo::A
      | Foo::B => println!("AB"),
      Foo::C => println!("C"),
   }
}
2

It would have to be written and accepted in the next 2 hours.

3

I don't see the teaching burden of adding it. (Unlike argument impl Trait which is also coming and in my view makes things more complex.) (or long time stable &mut vec vs vec.iter_mut() )

4

I don’t have strong feelings on this change although if I had to pick a side, I’d be against it :slight_smile:

The more concerning aspect, to me, is the “rust should be lenient/flexible in syntax it accepts” sentiment that I saw mentioned in comments surrounding that RFC. I don’t know why that’s a goal, or a guiding principle. Over time, all allowed syntax will eventually end up in a codebase and I’d find that distracting and counterproductive.

Anyway, this thread is probably not the venue to discuss this at length :slight_smile:

3 Likes
5

i really dislike the idea to have many syntax options for the same think. It makes it imo harder for a beginner to understand the language since it raises questions like
"With syntax to use and why?", "Are there any differences and if not why have the different syntax in the first place?", "With way will run faster?" and so on

4 Likes
6

I think it's important to understand the goal here. As I said on IRLO, the point is not that some people have different tastes. It's to meet the goal that "a list can be written by repeating a valid syntax for a single item", which is helpful for macro authors, for codegen tools in general, and allowing stylistic syntax choices that help minimize diffs.

That's why you can write foo(a, b) as

foo(
    some_really_long_thing_here,
    another_really_long_thing_here,
)

And similarly for bounds (T: Send+ Sync+) and where clauses (where T:Foo, U:Bar,) and struct fields (struct Foo { a:i32, b:i32, }) and generic parameters (< T, U, >) and arrays ([ 1, 2, 3, ]) and now match arms too (match foo { |A |B => ... }).

(One could debate whether leading vert or trailing vert is best, but one extra vert is consistent and good.)

6 Likes
7

I expressed a -1 vote on this anti-feature, and I still think it's a bad idea introducing an alternative syntax to do something. And justifying the introduction of cruft and messy code because "it's good for macros" is bad.

5 Likes
8

Why not just format it like this?

fn main() {
  let x = Foo::A;
  match x {
      Foo::A |
      Foo::B => println!("AB"),
      Foo::C => println!("C"),
   }
}

I see no value in the leading |.
The lines with => and without are different anyway.

2 Likes
9

what exactly is leading vertical bar consistent with?
while, I can agree with being consistent leads to easier to follow code. every example, I saw for this "feature" was to write in style that can be perfectly emulated with out adding this

10

That's also a stylistic choice. You could instead have it be

  match x {
      | Foo::A
      | Foo::B
      => println!("AB"),
      | Foo::C 
      => println!("C"),
   }
3 Likes
11

i thing an optional pipe in the end would be just as good for macros and more consistent with the rest of the language

match x {
    Foo::A |
    Foo::B |
    => println!("AB")
    ...
}
3 Likes