Switch expressions currently disallow trailing comma

[gafter]

Update: LDM (1/9) decided to allow such trailing comma.

---

@jcouv commented on Thu Dec 20 2018

Trailing commas are currently disallowed, which is inconvenient when copy/pasting a line.

public class C 
{
    public void M() 
    {
        _ = 3 switch 
        {
                2 => 1,
                _ => 2, // error
        };
    }
}

Example

In contrast, we allow trailing commas in array initializers.

---

@CyrusNajmabadi commented on Thu Dec 20 2018

A big :+1: on this. For anything that is commonly multi-line, not allowing the trailing comma is often a PITA. Thanks!

---

@gafter commented on Thu Dec 20 2018

I advocated for this but the LDM shot it down. I'll be happy to bring it back up based on "experience".

---

@CyrusNajmabadi commented on Thu Dec 20 2018

That would be great. Thanks @gafter .

---

@alrz commented on Thu Dec 20 2018

Hopefully also for property patterns which is an unordered list. 👍

---

@sharwell commented on Thu Dec 20 2018

@gafter This will be super obvious to StyleCop Analyzers users if it turns out to be a "special" list (i.e. a list that does not allow a trailing comma). There's a rule for that.

[CyrusNajmabadi]

Why not alter the language to treat a trailing comma as legal here but issue a warning? Then the user can - if they so choose - either tolerate and ignore the warning or not?

1. because warnings are effectively errors.
2. because warnings should be offered when there is something valid to warn about. i.e. something that is very very very very likely a problem. That's not hte case here. There is nothing wrong here. THat's the point. It's a very reasonable coding pattern that we want to strictly allow and support.

That said, if you don't like this you are totally capable of writing your own analyzer to detect and prevent using this. This is super common in the industry and people often write these sorts of 'linters'. I would not be surprised if StyleCopAnalyzers adds support for this, likely with options to require this for people that want it, or disallow it for people that don't. The language will support this being optional (like it does in other places), and users can decide which approach they want to take.

[CyrusNajmabadi]

The hypothetical explorations of languages that woudl not use separators doesn't seem to really be buying much here. C# has separators. They're not going anywhere. This discussion is about what exceptionally tiny tweaks the grammar should allow in order to make the coding/editing experience nicer :) It's def not about large scale discussions about whether or not separators should even exist :)

[Korporal]

It seems that this entire thread is discussing a change to a language feature that is not even released yet. That wasn't obvious to me.

[CyrusNajmabadi]

@Korporal No worries! Glad that was cleared up :)

[gafter]

Fixed in https://github.com/dotnet/roslyn/pull/32432 but still needs to be fixed in the specification.

[gafter]

Fixed in #2171