Proposal: Permit trailing commas in method signatures and invocations

[MgSam]

Migrated from dotnet/roslyn#12496

Proposal

Allow trailing commas in method/constructor declarations and invocations.

void Foo(
    int bar, 
    int baz,
) { }

Foo(
    bar: 5,
    baz: 3,
);

Rational

One very small but appreciated feature in C# is the tolerance of the compiler for trailing commas in array initialization or object initialization:

var a = new int[] 
{ 
    3, 
    4, 
    5, 
};
var b = new 
{ 
    Bark = "woof", 
    Bite = "chomp", 
}

This makes it easier to reorder or edit the item order without taking time to make sure that last comma gets deleted.

It would be nice if this feature also extended to method signatures and invocation. It would be especially useful in the post C# 4.0 where named parameters can be reordered or used to make a highly descriptive method call.

Example

void Foo (int bar, String baz, Func<int> cat, Action<String> dot, int elf) { }

Foo(
    bar: 5, 
    baz: "",
    cat: () => 6,
);

Wait, having cat last is confusing, let me place it after bar...

//Rather than just copy and paste the relevant line...
Foo(
    bar: 5, 
    cat: () => 6, //Now I need to add this comma here!
    baz: "" //And I need to remove this comma here!
);

Instead, if method invocations were also tolerant of an extra comma, it would make editing easier:

Foo(
    bar: 5, 
    cat: () => 6, 
    baz: "", //Extra comma here, it's not hurting anyone!
);

Final thoughts

TypeScript has and soon JavaScript will have this feature. I think it will work great in C# as well.

[DavidArno]

    baz: "", //Extra comma here, it's not hurting anyone!

It's hurting readability, simply to make the lives of lazy developers easier. It's bad enough that C# already supports superfluous commas in some cases already. Extending that to other cases would be very sad development.

[Pzixel]

@MgSam it's easy to write and hard to read. As you know, 80% of time you are reading the code. Thus this should be never get implemented.

[jveselka]

@DavidArno

It's hurting readability

How? Whats so confusing about it?

...simply to make the lives of lazy developers easier

Of course - thats what all language features are about

It's bad enough that C# already supports superfluous commas in some cases already.

Its already allowed at least on enums and object initializers and how is it bad there? Did it ever caused you any issues?

Frankly, I do not understand why would anyone oppose this improvement.

[wanton7]

I think IDE should be responsible of adding and removing commas when you paste something. Example if you paste something inside list or array initialization. But this shouldn't be added to language.
TypeScript probably added this because it's in some future JavaScript spec.
This just adds noise to language (hurts readability).
This probably wouldn't be so big of an issue if C# had standard formatter like golang has. If you add this that comma will be all over the place.

I can see this happening

var a = new int[] 
{ 
    3, 
    4, 
    5
, 
};

[alrz]

Trailing commas are usually allowed when it doesn't affect type or binding. e.g. object initializers, probably match, etc. In an argument list it does affect binding (because of overload resolution), however, with named arguments it is not always significant.

[DavidArno]

@zippec,

It's hurting readability
How? Whats so confusing about it?

I refer you to my answer to a near identical question from a year ago:

---

"I'm aware it's optional; that's it's problem. When looking at a piece of code with a trailing comma, one must ask: is it there because the author likes to use them, because they forgot to refactor, or because something has been missed and thus it could be a bug. They create a serious hindrance to readability just to pander to developers who want their lives made fractionally easier when writing the code."

---

Frankly, I do not understand why would anyone oppose this improvement.

Because some of us see their use as indicative of sloppy programming practices that favour making code easy to write over easy to read.

[svick]

@alrz

In an argument list it does affect binding (because of overload resolution)

Do you have an example? I tried a trivial example of adding the trailing comma in current compiler and the error I got was:

error CS1525: Invalid expression term ')'

It seems the compiler never reached the overload resolution phase.

[orthoxerox]

I have to write a lot of SQL at work, and the lack of trailing commas is the bane of every SQL programmer (any probably of every programmer that has to write JSON, too). While I do not think the arguments are edited that often to really require support for trailing commas, I also do not oppose this idea.

[alrz]

@svick

I meant the number of arguments, for example you could add property initializers without changing the return type, so it's safe to allow it there. But if you add an argument it might change the selected method.

[HaloFour]

punctuation means something to scatter it about just to placate formatting or decades-old diff technology is silly we have refactoring tools which manage the proper placement of commas on reordering members or arguments

[jnm2]

I'm torn. On one hand trailing commas irritate me whenever I see them; on the other hand, it would be more consistent with the rest of the language.

Much as I instinctively dislike this, punctuation exists to serve the wishes of those who use it and no one would be forcing me to use it that way.

[alrz]

As it is a matter of code style, an analyzer could preserve, insert, remove or prohibit usages in the code, so I wouldn't mind even if it would be allowed everywhere in the language that we have a list-like construct.

[MgSam]

@HaloFour It has nothing to do with diff tools. Anyone who does a lot of editing of code with long method invocations with many named parameters runs into this. As @orthoxerox said, the problem is even more acute in SQL, and in my personal experience, some of those invocations of which I speak are calls to SQL stored procs or tables.

The fact that JS is adding this feature in 2017 means that a committee comprised heavily from the biggest tech companies ratified it. That's a pretty big hurdle to cross. It's not some poorly thought out artifact left over from the language's inception like some other JS features. I think that's a pretty good indication that the use case here is real and pervasive.

[HaloFour]

@MgSam

Anyone who does a lot of editing of code with long method invocations with many named parameters runs into this.

Indeed I have. Many, many, many times. Particularly with SQL and particularly with stored procs with dozens of parameters. Or tables with dozens to hundreds of fields. It's of the most minor of inconveniences and not one that I feel deserves special punctuation rules. Developers should probably be forced to manually fix their code more often after a bad copy&paste.

[MgSam]

It's definitely minor, and it only takes a second or two to correct. But correcting interrupts your train of thought. And when this happens a few times a day, everyday, the time adds up.

[snebjorn]

JavaScript was able to do trailing commas and it's awesome! JavaScript pretty must runs the world. so if that was able to do it then C# also should 😄

I see comments about "preference and readability". Lets not forget that the trailing commas are optional. If you don't like them or it makes it harder for you to read. Then don't use them.

[MixusMinimax]

Cognitive science is mainly to be applied to natural languages. A list of arguments is not a sentence, it is a list of arguments. And yes, if you don't like it, then don't write trailing commas, that's what formatters are there for to enforce. But the arguments for merge conflicts, consistency, etc. strongly outweigh "idk it's not as nice to read". That's an argument to not use the feature, sure.

[jnm2]

That said, C# has never been a whitespace sensitive language, so it's irrelevant whether we're talking single- or multi-line.

For questions of formatting and readability, whitespace has never been irrelevant.

[theunrepentantgeek]

Lets not forget that the trailing commas are optional. If you don't like them or it makes it harder for you to read. Then don't use them

This is only relevant for toy projects that will only ever have a single developer.

As soon as you start working on anything with a meaningful size, you're looking at contributions from multiple developers over multiple years.

Later devs don't get a choice, they have to deal with whatever their predecessors have done.

Arguments of "If you don't like it, don't use it" always founder on this fact.

[snebjorn]

As soon as you start working on anything with a meaningful size, you're looking at contributions from multiple developers over multiple years.

Later devs don't get a choice, they have to deal with whatever their predecessors have done.

Code style is a team decision. They can change in the lifetime of a project. When they do you run the formatting tool with the new settings. I don't see a problem here.

[mrwensveen]

For me, the inconsistency between initializing a record type (constructor) and a class with properties annoys me the most because the use case is so similar. If it only were to be allowed in collection initializers then I would be okay with it (kind of).

Some people have argued that it's bad enough that C# allows it in other places but that's a matter of opinion. The feature clearly made it through, presumably with people arguing for and against the feature.

So, while I think this feature would be nice, I feel more strongly about the language being inconsistent with regards to trailing comma's.

[bw-flagship]

The (quite new) language "dart" allows trailing commas. IDEs make use of this and automatically break lines if you add a trailing comma on method calls, constructors, etc. Switching from back to coding c# from coding dart feels like a downgrade because this is not possible.

[KennethHoff]

With the introduction of Primary constructors I think this "issue" should be looked at. You may wonder what Primary Constructors have to do with anything, so here's my argument (pun intended):

Previously whenever you wanted to add or remove a field from a class you had to do it many places; Add the field, add a parameter to the constructor and set the field from the parameter (And obviously the same thing in reverse for removing), so adding/removing a single comma wasn't that big of a deal.

Now on the other hand you only have to change a single line to do all those three things mentioned previously, so the removal of a comma is now a majority of the time spent. Instead of simply pressing shift-delete (default keybind in Rider for deleting an entire line), you also have to go up a line and remove the comma.

(This is in addition to all the other arguments mentioned above, like consistency with initializers)

[beppemarazzi]

Or, in other words, in many context (i.e. initialization list, argument list, ...) the comma will act as a "terminator" not as a "separator". Exactly like the semicolon does with statements. (https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)#:~:text=A%20statement%20separator%20demarcates%20the,end%20of%20an%20individual%20statement.).
It's another (little) point in favor of this proposal to make the whole language more self consistent...

[Bigsby]

This would improve code versioning because, when adding items to lists (e.g., function parameters) only the added line is marked as changed and not the previous last line where the comma was added.

[TheBrambleShark]

Coming over from #8190

This is very useful when targeting multiple TFMs. Take this example that's currently impossible today:

/// <summary>
/// Represents a 9-digit United States social security number.
/// </summary>
[PublicAPI]
[DebuggerDisplay($"{{{nameof(GetDebuggerDisplay)}(),nq}}")]
public readonly struct SocialSecurityNumber
    : IFormattable,
    IEquatable<SocialSecurityNumber>,
#if NET7_0_OR_GREATER
    IEqualityOperators<SocialSecurityNumber, SocialSecurityNumber, bool>,
#endif
#if NET8_0_OR_GREATER
    IUtf8SpanFormattable,
    IUtf8SpanParsable<SocialSecurityNumber>
#endif
{
    // Specification omitted
}

Such is only possible with trailing commas allowed.

There are a couple work-arounds, such as SQL-style commas, but style rules may prohibit this:

/// <summary>
/// Represents a 9-digit United States social security number.
/// </summary>
[PublicAPI]
[DebuggerDisplay($"{{{nameof(GetDebuggerDisplay)}(),nq}}")]
public readonly struct SocialSecurityNumber
#pragma warning disable SA1001 // Commas should not be preceeded by whitespace.
    : IFormattable
    , IEquatable<SocialSecurityNumber>
#if NET7_0_OR_GREATER
    , IEqualityOperators<SocialSecurityNumber, SocialSecurityNumber, bool>
#endif
#if NET8_0_OR_GREATER
    , IUtf8SpanFormattable
    , IUtf8SpanParsable<SocialSecurityNumber>
#endif

Partial classes are another option, but this doesn't make sense in all cases.

[mikernet]

@Foxtrek64 Just FYI, you can also do:

public readonly struct SocialSecurityNumber :
#if NET7_0_OR_GREATER
    IEqualityOperators<SocialSecurityNumber, SocialSecurityNumber, bool>,
#endif
#if NET8_0_OR_GREATER
    IUtf8SpanFormattable,
    IUtf8SpanParsable<SocialSecurityNumber>,
#endif
    IFormattable,
    IEquatable<SocialSecurityNumber>
{
}

[aradalvand]

The use cases are patently clear and justified. Source generators, TFMs, consistency, diffing, etc. This one little trivial-to-implement feature, which almost every other modern language already has, would improve the experience in all those areas.

So why not just do it and get it over with?

[CyrusNajmabadi]

So why not just do it and get it over with?

Because our plates are full with lots of other work.

[miyu]

If this is implemented, it'd be consistent to support trailing commas in array indexers too. This would be useful for a variety of niche DSLs that I've seen... Trivial examples would be DSLs which index by filter condition or slice N-dimensional data grids.