On Fri, 2024-03-01 at 20:45 +0000, Jonathan Wakely via Std-Proposals wrote:
On Fri, 1 Mar 2024 at 15:53, Tom Honermann <tom@honermann.net> wrote:

On 3/1/24 6:43 AM, Jonathan Wakely via Std-Proposals wrote:
On Fri, 1 Mar 2024 at 01:53, Zhihao Yuan via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
On Thursday, February 29th, 2024 at 10:48 AM, Tom Honermann via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

See also P0281R0 (Remove comma elision in variadic function declarations). EWG rejected the paper during the Jacksonville, 2016 meeting. There isn't much for meeting minutes. From what I recall, concerns were mostly about the potential to break existing code.

My view: ship it.


My view: ship it.

And prove my stand-up outdated: https://youtu.be/PSvJ_j4rKOE
I'm glad I'm not the only one who enjoys the hexadot.


Hmm, usage in a system header. And that isn't the only use.


That last one is tr1, so I'm not sure it matters much. The paper should
probably note these uses. They probably don't affect deprecation since
deprecation warnings are typically suppressed for uses in system
headers, but they could be an issue for removal. This suggests getting
some implementation experience might be worthwhile as well (e.g., add a
warning to gcc, build it and libstc++, run the testsuite).

Libstdc++ headers are changed in lockstep with GCC itself, so if this
change goes ahead I'll just add the commas to libstdc++ (and weep
quietly to mourn the loss of the hexadot).

There's a minor issue for libstdc++ headers being consumed by non-GCC
compilers, so somebody trying to use today's libstdc++ headers with a
version of Clang that implements this proposal would be an issue.

You could commit the comma ahead of the deprecation (less cleverness == improvement) and backport them to clear the field.

thinking is that if you're trying to use -std=c++2c -stdlib=libstdc++
with clang then you had better make sure you have up-to-date libstdc++
headers. It's not reasonable to expect headers from 2024 to support
-std=c++2c well.

Uses in non-stdlib code are more of a concern.