More trailing commas

Contents

1. Revision history

1.1. Changes since R0

• cited EWG polls in §2.1. Recent history
• expanded and updated §2.2. Trailing commas in other languages
• expanded §3.3. Code generation convenience, referenced [P3294R2]
• elaborated on ClangFormat options in §3.4. Improved auto-formatter control
• added §3.7. Preventing string joining bugs
• reworded §4.4. Comparison to P0562R2
• expanded §5. Addressing criticisms based on EWG reflector discussion
• added Clang fork as §6. Implementation experience
• added feature-test macro to §8. Wording
• added §9. Acknowledgements
• various minor/editorial changes

2. Introduction

C++ permits the use of trailing commas in some lists, but not in others. For example, trailing commas are permitted at the end of an initializer-list, but not following a mem-initializer-list, capture-list, template-parameter-list, expression-list, in a postfix-expression, etc. It would be convenient if the support for trailing commas was extended to those other lists.

For example, the following should be valid:

2.1. Recent history

While this proposal is new, a very similar proposal [P0562R2] has passed through EWG in Tokyo 2024. [P0562R2] argues in favor of trailing commas following mem-initializer-list and (following EWG feedback) base-specifier-list, with similar rationale as this proposal.

Poll: D0562R1 — Initialization List Symmetry: also add support for base class trailing commas.

SF	F	N	A	SA
18	10	2	1	0

Result: Consensus

Poll: D0562R1 — Initialization List Symmetry: forward the paper (with the addition of base class trailing comma) to CWG for inclusion in C++26.

SF	F	N	A	SA
12	11	4	3	0

Result: Consensus

However, the subsequent revision [P0562R2] was not polled due to implementability concerns: a comma after a mem-initializer-list introduces a parsing ambiguity between initializer lists and function bodies; see Richard Smith's explanation at [P0562R2ReflectorDiscussion]:

Classes are parsed in two phases: first, declarations are parsed, skipping the bodies of member functions and a few other things, and then those delayed parts are parsed in a context where the class is complete.

For most functions, skipping the body in the first pass is easy. There's an open brace, and you can just skip to the close brace. At worst, there's try {, and you need to find the end of the last catch handler.

The problem is that a mem-initializer-id can be a template-id that refers to a base class, and the identifiers it uses to name the base class might be declared (possibly after the constructor) in the same class — meaning that we've not parsed them yet. Therefore when we see a <, we don't know if it's introducing a template argument list. For example:

struct X {}; struct Y : X { Y() : A<b<c>(), { // ... } // A, b, and c declared down here somewhere };

Are we in the body of the constructor yet?

Prior to P0562R2, the answer was no: an open brace preceded by a comma cannot start the constructor body. For this to be valid, b must be a template, and the { is then the start of the second template argument of A. ([…])

But after P0562R2, the above example seems to become ambiguous, and I'm not sure how an implementation would be able to parse it.

Following these developments in St. Louis 2024-06, the proposal has seen no activity. It seems like the baby has been thrown out with the bathwater here, since the rationale of the proposal is still sound and this ambiguity does not affect base-specifier-lists.

2.2. Trailing commas in other languages

Various modern programming languages support trailing commas, not just in initialization of classes or when listing enum members, but also in function parameter lists or function argument lists. We can see a clear trend:

To the best of my knowledge, trailing commas have been well-received by the users of these languages, to the point where they are the default in e.g. the Rust Style Guide. The motivation to have trailing commas in those languages equally applies to C++, and is largely covered in §3.1. Improved text editing and §3.2. Improved version control.

3. Motivation

While trailing commas don't solve any major safety or performance issue, they improve developer convenience significantly in some ways. Given how many comma-separated lists developers regularly write, this convenience can be noticeable on a daily basis.

3.1. Improved text editing

Advanced text editors typically have commands for cutting/copying whole lines, or let the developer reorder lines via keyboard shortcut. For example, a line can be swapped with the line above with Alt+ ↑  in VSCode. This can result in compiler errors without trailing commas:

When reordering int x, and int y, errors are raised:

If both lines had a trailing comma and C++ permitted that syntax, reordering these lines would not be a problem.

3.2. Improved version control

When an element is appended to a comma-separated list, this means that the previous element needs to receive a separating comma, resulting in menial changes:

With trailing commas, we can turn a three-line change into a one-line change:

This smaller change is not just easier to review, it also does not pollute the revision history (git blame) for the previous line of code, and it does not introduce easily avoidable merge conflicts.

3.3. Code generation convenience

Allowing trailing commas makes it easier to generate C++ code, for similar reasons as in §3.6. Eliminating some uses of __VA_OPT__. Generating lists is sometimes made easier if each element in a list can be terminated by a comma, rather than adding special handling for the first/last element to ensure no trailing commas in generated code.

A number of WG21 members have expressed that this code generation convenience is important to them:

In cppfront I resisted supporting trailing commas for a couple of years, despite frequent pleas from users. What finally made me cave and allow redundant trailing commas in all comma-lists was reflection, especially the generation part of reflection: When generating new code, writing the special-case code all the time to not emit a comma at the end is not hard, but it comes up frequently enough to be an irritation (think: most generated function declarations, and a significant minority of function calls which matters because #calls >> #decls). It's just simpler not to have to have to write that comma logic when generating new code... it's like stopping the "water torture" of incessant little drips none of which is significant in isolation but drive you crazy with constant ceaseless repetition.

— Herb Sutter

3.4. Improved auto-formatter control

Many C++ developers auto-format their code using ClangFormat. One powerful feature it has is the ability to control how brace-enclosed lists are formatted via the use of trailing commas.

Trailing commas express the desire to format over multiple lines, which auto-formatters may utilize. Without support for trailing commas in e.g. function parameter lists, the developer is robbed of their ability to (elegantly) express that desire, since doing so would make the program ill-formed.

3.5. Improved language consistency

It is generally surprising that C++ only supports trailing commas within a subset of its comma-separated lists. Besides the design not sparking joy, it creates practical problems.

For example, when refactoring code and e.g. converting list-initialization such as {1, 2, 3,} which already uses trailing commas into direct-initialization (1, 2, 3,), the trailing comma introduces a compiler error until it is removed, which is a mild inconvenience at least.

3.6. Eliminating some uses of __VA_OPT__

When we want to prepend an element to a variadic macro argument, we may need to use __VA_OPT__ in the following way:

With an unconditional comma, F() would expand to f(0,), which is currently ill-formed. A trailing comma in function calls and other lists would allow us to simplify such macros.

3.7. Preventing string joining bugs

When appending a string literal to a list of arguments and forgetting to add a comma, our code may compile, but do the wrong thing:

Rather than passing a four arguments, the effect is as if the third argument was "foe" "fum", which is valid and equivalent to "foefum". Among other causes, this may happen when pasting the line containing "fum" into position.

This bug would be prevented by the use of trailing commas. Even if we forget a comma after "fum", there should already be one after "foe", so nothing surprising happens:

Furthermore, our linter or auto-formatter should enforce the use of commas there, making the bug much easier to find.

3.8. Motivating examples

In discussions of this proposal, there is often some skepticism as to whether it's useful for specific lists. For example, I have been told that trailing commas may be useful in a template-parameter-list, but not in a template-argument-list. However, while some lists are more frequently multi-line, you can come up with a plausible multi-line example for virtually any list:

For any of these list types, it is plausible that they are long enough to be broken onto multiple lines, and it is plausible that changes will be made to such lists in the future, which makes a trailing comma useful in these lists.

4. Design

I propose to add a trailing comma after a list whenever possible (i.e. no parsing issues are introduced), with the exception of lists terminated by a semicolon. The design can be summed up as:

When enclosed by {}, (), [], or <>, lists can have a trailing comma.

All the following decisions are intended to make that rule of thumb correct. Cherry-picking individual cases like permitting array[a,b,] but not [a,b,]{} would only complicate the situation.

4.1. New trailing commas

The following trailing commas are proposed, and not currently permitted.

While this initially appears like a huge change, it can be easily worded by incorporating the trailing comma directly into lists such as expression-list, since every occurrence of these lists would allow for trailing commas.

4.1.1. Addressing ambiguity concerns

Note that all of these proposed cases are safe from parsing ambiguities encountered by [P0562R2]. That is because a the trailing comma can only be followed by '}', ')', ']', or '>'. In the first three cases, a closing bracket cannot possibly be the beginning of a new element, only the end whatever encloses list. Neither '>', '>=', nor '>>' are prefix unary operators, so in any case, ',>' can only mean one thing.

Furthermore, operator, cannot be separated into operator and ',' or combined into operator,> (there is no ',>' operator in the language), so no ambiguity can be introduced by having operator appear at the end of a list.

4.2. Already supported trailing commas

The following trailing commas are already supported:

4.3. Not proposed trailing commas

4.3.1. Commas proposed in P0562R2

The following two trailing commas are proposed by [P0562R2] and should be added, if at all possible, as a revision of that paper.

While the parsing ambiguity (§2.1. Recent history) seems limited to a mem-initializer-list, a base-specifier-list is similarly followed by {, which makes it quite plausible that similar parsing issues could affect that case. In any case, to keep this paper focused, I do not propose those two commas.

4.3.2. Trailing commas in semicolon-terminated lists

Two more commas are not proposed because they are in semicolon-terminated lists:

Firstly, for aesthetic reasons, it is unlikely that users would want to write this. Furthermore, multiple elements in a init-declarator-list are already discouraged by some style guides. Last but not least, the §3. Motivation of this paper focuses on multi-line scenarios. In the aforementioned cases, to make good use of trailing commas, developers would need to write:

Not only is this exotic, it is also more verbose than the status quo, which already allows reordering lines if we instead write:

Overall, permitting trailing commas in a init-declarator-list or using-declarator-list seems unmotivated, and would create unnecessary work for implementers.

4.3.3. Non-lists

The following trailing commas are not proposed because they are not following a list:

While it may be more philosophically consistent to permit a comma within anything that vaguely looks like a function call, there is little motivation for such cases above. To be fair, a trailing comma could yield a minimal one-line change as follows:

However, it seems unlikely that a developer would choose to distribute a no-message static_assert over three lines in the first place. Overall, these cases just seem to add more work for implementers.

4.3.4. Commas following ellipsis parameters

Another not proposed trailing comma is that after an ellipsis parameter:

This decision is largely based on negative feedback in [CoreReflectorDiscussion].

The trailing comma in this place is largely unmotivated because the ellipsis is always the last element in the list. Consequently, a ... line cannot be reordered with the line before, and a comma will never have to be inserted after ... to accommodate a subsequent element.

4.3.5. Commas in macros

The following trailing commas are not proposed:

The former lacks motivation because it is highly unlikely that a C++ use would define multi-line parameters to a function-style macro. Doing so requires each parameter line to be terminated by \, among other reasons.

Supporting trailing commas in M(x,y,) would alter the meaning of existing code. Currently, that expression is providing three arguments to M, the last of which is empty.

4.4. Comparison to P0562R2

It is worth noting that [P0562R2] did not propose trailing commas in function and template parameters with the following rationale:

Function and template parameters do not allow a final terminating comma, but these do not trouble me in practice. (Arguably any function or template with enough parameters to be much of a maintenance issue seems like it is ripe for refactoring.) This paper does not propose changing function or template parameters.

Note that [P0562R2] argues that additional trailing commas for mem-initializer-lists make "maintenance" easier. Maintenance equally motivates trailing commas in function parameter lists. However, [P0562R2] holds function parameter lists to a double standard where if you maintain such lists, they are "ripe for refactoring" anyway.

This position is poorly motivated and out-of-touch with language development at large. Trailing commas in function parameter lists have recently been added to various programming languages (§2.2. Trailing commas in other languages). In fact, developers write tremendously more function parameter lists and argument lists than mem-initializer-lists, so the former are more deserving of attention.

5. Addressing criticisms

5.1. Aesthetic objections

I have unofficially polled the idea of trailing commas on social media prior to drafting this proposal, and a surprising amount of people objected to the idea. Some negative feedback was also given on R0 of this paper on the EWG reflector. A surprising amount of negative feedback revolved around aesthetics, ranging from "it looks ugly" to "this makes me deeply uncomfortable". This is a valid concern. Since trailing commas are foreign to both natural language and mathematical notation, I can sympathize with this position. However, we must keep some things in mind:

• Trailing commas are entirely optional, so if they cause one discomfort, it is possible to avoid them, at least in one's own personal projects and possibly their code at work.
• Aesthetic perception is heavily influenced by familiarity. A Python developer likely perceives C++' use of special characters in (!x && y) or int(T::*) as "ugly". To many, it is easy to get used to trailing commas. Since they are intended for multi-line scenarios, there is a fair amount of distance between ',' and e.g. > anyway.
• The job of WG21 is to standardize a programming language used by software engineers. Trailing commas have clear technical benefits laid out in §3. Motivation, and clear technical benefits should always take precedence over aesthetics. If we had gotten hung up over the aesthetics of ^^ and [::], C++26 reflections would have died.

5.2. Concerns over C compatibility

Some concerns have been raised regarding the fact that only C++ but not C would support the use of trailing commas. This was alleged to make writing common C and C++ code harder.

However, the use of trailing commas is entirely optional, so this claim is untrue. It is not a stated design goal of C++ to make every possible line of C++ code valid C as well. Instead, we maintain a common subset that is both valid C and valid C++. If a developer wants to write C/C++-interoperable code, they can simply not use trailing commas.

Furthermore, I intend to follow this proposal up with a WG14 counterpart if it finds consensus. For the sake of C++ compatibility, it is plausible that WG14 would adopt the syntax as well; this has been done with numerous features before.

5.3. Making previously ill-formed code valid, possibly inviting bugs

Some people consider it a benefit that f(0,) is currently not allowed, which may catch mistakes in some scenarios:

Maybe I was typing, distracted, and forgot my last argument? Maybe a macro expanded badly?

However, there are numerous counter-arguments to this concern:

• Single-line trailing comma uses like f(0,) (which are unmotivated, and most likely how such a mistake is spelled) can also be diagnosed by linters and compilers. This would be similar to the only-multiline string option for ESLint Stylistic's comma-dangle rule.
• C++ is a statically typed language, so forgetting an argument, whether spelled f(0) or f(0,), likely results in an error anyway (no matching overload).
• We know based on C++ user experience with trailing commas in braced lists as well as user experience from other languages with trailing comma support, that this is not rampant problem. I was unable to find an authoritative style guide for any language that recommends against the use of trailing commas. One would expect such a style guide to exist if trailing commas were a common source of bugs.

Last but not least, it is worth remembering one of C++' design principles (see Design and Evolution of C++ — 4.3 Design Support Rules):

It is more important to allow a useful feature than to prevent every misuse.

5.4. Semantic inconsistencies with macros

With the proposed syntax in function calls, f(0,) would be valid for both regular functions and for function-style macros. The trailing comma has different meaning in those two:

This inconsistency cannot be changed without altering the semantics of the preprocessor, so it is here to stay. However, the syntax of function-style macro expansions and function calls is already inconsistent:

As things stand, function calls need to be "massaged" a bit to also be valid macro expansions, e.g. via the use of parentheses. Users who are uncertain about whether f is a macro can choose not to use a trailing comma; it is entirely optional. Furthermore, trailing commas in variadic macros "just work":

5.5. Multiple ways to do the same thing

A common and generally good rule of thumb in programming language design is:

Don't introduce multiple ways to do the same thing.

It could be argued that we can already spell parameter lists without a trailing comma, so it is bad to add a second way. However, this rule is not universally and innately true; it is important to understand why one may follow it:

• Multiple ways of doing the same thing makes a language harder to teach.
• If we can already do the same thing a different way, no value is added to the language.

The first motivation hardly applies because C++ already supports trailing commas in some lists. One could argue the language becomes more teachable by fixing this inconsistency and permitting it in all lists. Even if that argument is not accepted, the teaching effort for an optional punctuation character is microscopic.

Secondly, §3. Motivation lays out numerous ways in which trailing commas add value to the language. It would be hard to argue that // line comments add no value to the language because /* block comments */ exist, or that 1s adds no value because std::chrono::seconds(1) exists. It is fine to have multiple spellings of the same feature when there are clear technical benefits to both spellings. There are no hard rules in language design, only trade-offs and rules of thumb.

5.6. Claiming syntax space

Concerns have been expressed that permitting trailing commas would claim syntax space, so that f(0,) could not be given other meaning in the future. Specifically, empty list elements could be given special meaning, such as using a default argument:

Firstly, note that f(1,) has the effect of passing a default argument for y, no matter the meaning of a trailing comma. f(1,1,) would be a special case, but in principle, trailing commas are compatible with these hypothetical semantics.

Secondly, I consider this idea terrible because of how non-descriptive it is; a user could even unintentionally perform such calls by making a typo ',,' somewhere in the argument list. Using the syntax f(1,1,) to mean anything other than a function call with two arguments and a trailing comma would be terribly confusing to developers accustomed to trailing commas from other languages, such as JavaScript or Kotlin developers (§2.2. Trailing commas in other languages).

Without a plausible alternative use for the syntax concerns over claiming syntax space have little relevance. Even the people bringing up these syntax space concerns are not confident that this "default argument passing" could find consensus.

6. Implementation experience

This proposal has been implemented by Can Çağrı in a [ClangFork], and can be tested at [CompilerExplorerDemo]. The implementation is a simple parser change of approximately 40 lines of code.

7. Impact on existing code

The proposal does not alter the meaning of any existing code; it only makes previously ill-formed code valid.

8. Wording

In [expr.prim.lambda.capture], change the grammar as follows:

In [dcl.pre] paragraph 1, change the grammar as follows:

In [dcl.fct] paragraph 2, change the grammar as follows:

In [dcl.init.general] paragraph 1, change the grammar as follows:

In [dcl.attr.grammar] paragraph 1, change the grammar as follows:

In [temp.pre] paragraph 1, change the grammar as follows:

In [temp.names] paragraph 1, change the grammar as follows:

If the proposed resolution of [CWGGithub754] at the time of writing has been applied, revert the change to [stmt.expand] as follows:

Add the following table row to [cpp.predefined] [tab:cpp.predefined.ft]:

9. Acknowledgements

I thank Barry Revzin and Matthias Wippich for helping me craft the example in §3.3. Code generation convenience.

I thank Herb Sutter, Mathias Stearn, Matthias Wippich, Lénárd Szolnoki, Alisdair Meredith, Gabriel Dos Reis, and many others for providing detailed feedback on this proposal, greatly improving its quality.

10. References