https://www.sandordargo.com/blog/2026/03/11/cpp26-oxford-variadic-comma avatar Sandor Dargo's Blog On C++, software development and books * HOME * TAGS * ARCHIVES * BOOKS * SPEAKING * DAILY C++ * HI... * [become_a_p] Blog 2026 03 11 C++26: The Oxford variadic comma Post [ ] Cancel C++26: The Oxford variadic comma Sandor Dargo Mar 11 2026-03-11T00:00:00+01:00 4 min 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: 1 void foo(int, ...); // with comma (C-compatible) 2 void foo(int...); // without comma (C++-only) 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: 1 // In C, only this form is valid: 2 int printf(char*, ...); 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: 1 template 2 void f(Ts...); // well-formed: a parameter of type Ts followed by an ellipsis parameter 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: 1 template 2 void f(Ts... args); // args is a parameter pack The situation gets even more confusing with abbreviated function templates: 1 // abbreviated variadic function template 2 void g(auto... args); 3 4 // abbreviated non-variadic function template with ellipsis parameter 5 void g(auto args...); 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: 1 void h(auto......); // equivalent to (auto..., ...) 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: 1 // Deprecated in C++26: 2 void f(int...); 3 void g(auto args...); 4 template void h(T...); // T is not a parameter pack 5 6 // Preferred (and C-compatible): 7 void f(int, ...); 8 void g(auto args, ...); 9 template void h(T, ...); The standalone ellipsis parameter remains valid: 1 void f(...); // still valid, C-compatible, unambiguous 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! [yH5BAEAAAA] dev cpp cpp26 variadics deprecation This post is licensed under CC BY 4.0 by the author. [yH5BAEAAAA] [yH5BAEAAAA] Share Recent Update * Time in C++: C++20 Brought Us Time Zones * Lesson of a booking: Don't trust the system! * Why should we always catch exceptions by reference? * Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain * Discovering observers - part 1 Trending Tags cpp books watercooler career tutorial cpp23 stl algorithms self-improvement management Contents Further Reading Jul 3, 2024 2024-07-03T00:00:00+02:00 C++23: further small changes In this article, let's get back to exploring C++23. We are going to have a look at some unrelated small changes in the standard, including the rarest species of changes. Deprecations! Printing vol... Dec 11, 2024 2024-12-11T00:00:00+01:00 Let's start exploring C++26 During the last 2 years, we spent a lot of time exploring C++23 resulting in almost 40 blog posts. I'm not saying that we covered every single new language or library feature, but we covered most o... Dec 18, 2024 2024-12-18T00:00:00+01:00 C++26: Delete with a reason Let's start exploring C++26 with a simple but useful change. Thanks to Yihe Li's proposal (2573R2), when we =delete a special member function or a function overload, we can specify a reason. This ... Frictionless by Nicole Forsgren and Abi Noda - Comments powered by Disqus. (c) 2026 Sandor Dargo. Some rights reserved. Powered by Jekyll with Chirpy theme. Trending Tags cpp books watercooler career tutorial cpp23 stl algorithms self improvement management