C++26: The Oxford Variadic Comma

I used to slay with this in code golfing competitions from TopCoder, where you had to implement a function to solve a particular problem, thanks to C pointer maths and the gcc generally putting function arguments in order in the stack.

Turns out, these two are equivalent in practice (but UB in the C++ standard):

    double solve(double a, double b, double c, double d) {
      return a + b + c + d;
    }

    double solve(double a ...) {
      return a + 1[&a] + 2[&a] + 3[&a];
    }

Of course since the old syntax is merely deprecated and not removed, going forward you now have to know the old, bad form and the new, good form in order to read code. Backwards compatibility is a strength but also a one-way complexity ratchet.

At least they managed to kill `auto_ptr`.

This seems pretty good to me just on the level of trying to read C as someone using C++. Parameter packs and variadic templates are easily the most confusing syntax in C++ and cleaning it up is... very welcome

C++ seems to be constantly getting complicated. If the major version were to change, there wouldn't be any need for backward compatibility with the existing code, and it would have been okay to delete that syntax while creating an automatic formatter.

Yes, but no. I learned C++ in '90s when it was C with classes and some other noise added by Stroustrup. During the some 25 years that followed it had became a mess that's insanely hard to work with. I'm not going back to this language. I prefer plain C or Rust, leaning towards Rust when I fully comprehend the lifetime and borrow checker. Or when I have the luxury of having a GCed runtime, then the .NET with its easiest C# language with wonderful abundance of great libraries is the best choice. Nobody was ever fired for using .NET (for right purposes).

learned something new. thanks for the article.

C++ got too complicated after C++23 I went back to C.

Turns out, these two are equivalent in practice (but UB in the C++ standard):

    double solve(double a, double b, double c, double d) {
      return a + b + c + d;
    }

    double solve(double a ...) {
      return a + 1[&a] + 2[&a] + 3[&a];
    }

> Turns out, these two are equivalent in practice

Not in the x86-64 SysV ABI they aren’t. The arguments will be passed in registers (yes, even the variadic ones), so how your compiler will interpret 1[&a] is anybody’s guess. (For me, x86_64-unknown-linux-gnu-g++ -O2 yields, essentially, return a+a+a+a; which is certainly an interpretation. I’m also getting strange results from i686-unknown-linux-gnu-g++ -O2, but my x87 assembly is rusty enough that I don’t really get what’s going on there.)

    double solve(double a[]) {
      return 0[a] + 1[a] + 2[a] + 3[a];
    }

    solve((double[]){1, 2, 3, 4});

The cast in the invocation can be macro-ed away. And the best thing is, the actual stack layout and data movement/shuffling is pretty much identical to the approach with <stdargs.h>, and with no UB or compiler intrinsics.

K&R syntax is -1 char, if you are in C:

    double solve(double a,double b,double c,double d){return a+b+c+d;}
    double solve(double a...){return a+1[&a]+2[&a]+3[&a];}
    double solve(a,b,c,d)double a,c,b,d;{return a+b+c+d;}

learned something new. thanks for the article.

Hats off for using "..." in your comment immediately after a valid identifier word and with no comma in between, given the topic of the article.

Are you suggesting we move to C++++?

C++ got too complicated after C++23 I went back to C.

You can always restrict yourself to a subset of C++ that takes advantage of RAII (resource handling is extremely painful in C), and get performance benefits like move semantics, without the insanely complex stuff.

I love C, but C++ has worthwhile advantages even if you heavily restrict which features you use.

No offense intended to your perspective, but I do find it a little amusing that C++23, which was generally considered a disappointingly small update due to COVID complications, was the breaking point in complexity.

At least they managed to kill `auto_ptr`.

PyCuda 2024, used fairly often in certain industries, still contains `auto_ptr` ;-;

> Turns out, these two are equivalent in practice

    double solve(double a[]) {
      return 0[a] + 1[a] + 2[a] + 3[a];
    }

    solve((double[]){1, 2, 3, 4});

K&R syntax is -1 char, if you are in C:

    double solve(double a,double b,double c,double d){return a+b+c+d;}
    double solve(double a...){return a+1[&a]+2[&a]+3[&a];}
    double solve(a,b,c,d)double a,c,b,d;{return a+b+c+d;}

I love C, but C++ has worthwhile advantages even if you heavily restrict which features you use.

Are you suggesting we move to C++++?

It's already there. It's called C#

Personally I like C+. Picking the nice parts of C++, but skipping all the nonsense. I just wish C++ hadn't deliberately screwed up designated initializers with mandatory ordering. The C version of it that allows out-of-order assignments is clearly superior.

Didn't you read the article? That form is deprecated. The recommended one is C,++,++

PyCuda 2024, used fairly often in certain industries, still contains `auto_ptr` ;-;

Hats off for using "..." in your comment immediately after a valid identifier word and with no comma in between, given the topic of the article.

Hats off for noticing. Not to be taken for granted in an increasingly skimming-oriented world

Didn't you read the article? That form is deprecated. The recommended one is C,++,++

It's already there. It's called C#

Well, C# also has its quirks already. Like the crippled finalizers which are never to be used. If the IDisposable interface had been correctly designed, finalizers could become be the "public void Dispose(void)". Or the manual passing of Task in case of async methods, which is... kinda smelly.

Hats off for noticing. Not to be taken for granted in an increasingly skimming-oriented world

It's possible you didn't realise, but C# is sometimes said to be named that way because # is the symbol you get if you draw ++ small and then on the line below ++ again. Hence C++++

All languages have some spikier edges, there are no languages I know where I think "Well, even if we could start over I have no idea how to improve this". What's notable about C++ is just how rich that "could do better" seam is, so very many of their defaults are wrong, so many of their keywords are the wrong word, so many of their standard library features are allowed, sometimes even mandated to be crap.

It's possible you didn't realise, but C# is sometimes said to be named that way because # is the symbol you get if you draw ++ small and then on the line below ++ again. Hence C++++

I don’t know if that’s true or not, but while the thought never crossed my mind before your comment, it’s now canon in my mind. Yes, C# is spelled C++++ with a ligature.

I think you meant to get that to the original poster, who seems to imply C# is the flawless, bestest incarnation of C\+\+(\+\+)+.

I don’t know if that’s true or not, but while the thought never crossed my mind before your comment, it’s now canon in my mind. Yes, C# is spelled C++++ with a ligature.

I think you meant to get that to the original poster, who seems to imply C# is the flawless, bestest incarnation of C\+\+(\+\+)+.

C++26 brings us a small but meaningful cleanup to the language: deprecating ellipsis parameters without a preceding comma. This change, proposed in P3176R1, aims to improve C compatibility, reduce confusion, and pave the way for future language features.

The proposal’s name is a playful reference to the Oxford comma - that final comma before “and” in a list. Just as the Oxford comma clarifies lists in English, this proposal mandates a comma before the ellipsis in function parameters.

The problem

First, let’s clarify terminology. This proposal is about ellipsis parameters - the C-style variadic parameters you might know from printf. These are different from template parameter packs, even though both use the ... syntax.

Currently, C++ allows two ways to declare an ellipsis parameter:

<table><tbody><tr><td><pre>1 2 </pre></td><td><pre>void foo(int, ...); // with comma (C-compatible) void foo(int...); // without comma (C++-only) </pre></td></tr></tbody></table>

The second form without the comma originates from early (pre-standard) C++ function prototypes, but has remained part of standardized C++ ever since. Interestingly, C has never allowed the comma to be omitted. The C standard, unchanged since C89, requires:

<table><tbody><tr><td><pre>1 2 </pre></td><td><pre>// In C, only this form is valid: int printf(char*, ...); </pre></td></tr></tbody></table>

C++ later added support for the comma-separated form for C compatibility, but kept the old syntax for backwards compatibility. This creates an awkward situation where (int, ...) is compatible with both languages, but (int...) only works in C++.

Why is this confusing?

The real confusion comes from template parameter packs, introduced in C++11. Consider this example:

<table><tbody><tr><td><pre>1 2 </pre></td><td><pre>template<class Ts> void f(Ts...); // well-formed: a parameter of type Ts followed by an ellipsis parameter </pre></td></tr></tbody></table>

Many users associate (T...) with a parameter pack, not with an ellipsis parameter. Instead, it’s a single parameter of type Ts followed by an ellipsis parameter! To actually declare a parameter pack, you need:

<table><tbody><tr><td><pre>1 2 </pre></td><td><pre>template<class... Ts> void f(Ts... args); // args is a parameter pack </pre></td></tr></tbody></table>

The situation gets even more confusing with abbreviated function templates:

<table><tbody><tr><td><pre>1 2 3 4 5 </pre></td><td><pre>// abbreviated variadic function template void g(auto... args); // abbreviated non-variadic function template with ellipsis parameter void g(auto args...); </pre></td></tr></tbody></table>

These two look similar but have completely different meanings. The latter should be deprecated.

The curious case of six dots

Perhaps the most bizarre syntax enabled by the current rules is this:

<table><tbody><tr><td><pre>1 </pre></td><td><pre>void h(auto......); // equivalent to (auto..., ...) </pre></td></tr></tbody></table>

Yes, that’s six consecutive dots - if I counted it right. This declares a function template parameter pack followed by an ellipsis parameter. While technically possible to use (if the pack belongs to a surrounding class template), the syntax strongly suggests all dots apply to auto, which is misleading.

What’s being deprecated?

C++26 will deprecate ellipsis parameters without a preceding comma. Specifically:

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 </pre></td><td><pre>// Deprecated in C++26: void f(int...); void g(auto args...); template<class T> void h(T...); // T is not a parameter pack // Preferred (and C-compatible): void f(int, ...); void g(auto args, ...); template<class T> void h(T, ...); </pre></td></tr></tbody></table>

The standalone ellipsis parameter remains valid:

<table><tbody><tr><td><pre>1 </pre></td><td><pre>void f(...); // still valid, C-compatible, unambiguous </pre></td></tr></tbody></table>

Impact

This is a pure deprecation - removal had been already refused before. No existing code becomes ill-formed. Any deprecated uses can be mechanically transformed by adding a comma before the ellipsis. This transformation is simple enough to be automated by tooling.

The proposal doesn’t estimate how much code will be affected, though the author found several dozen occurrences of the T...... pattern in a GitHub code search. The real number of affected declarations is likely non-trivial, finding them requires semantic analysis since (T...) could be either an ellipsis parameter or a parameter pack depending on context.

This deprecation clears the path for future language features. The syntax (int...) has already blocked proposals like P1219R2 “Homogeneous variadic function parameters”, which would have given this syntax a new meaning.

By deprecating the comma-less form, the committee preserves design space for future evolution while improving consistency with C and reducing a common source of confusion.

Conclusion

The Oxford variadic comma is a small change with multiple benefits: better C compatibility, reduced confusion with parameter packs, and preserved design space for future features. While the title is playful, the motivation is serious - cleaning up a historical artifact that serves little purpose in modern C++.

If you’re using ellipsis parameters, start adding that comma before the .... Your code will be more C-compatible, less confusing, and ready for whatever comes next.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let’s connect on Twitter!

Hacker Times