On Thu, Feb 29, 2024 at 4:07 PM Jens Maurer <jens.maurer_at_[hidden]> wrote:

> On 29/02/2024 20.50, Arthur O'Dwyer via Std-Proposals wrote:
> > On Wed, Feb 28, 2024 at 2:14 PM Jan Schultke via Std-Proposals <
> std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
> > The link
> https://eisenwave.github.io/cpp-proposals/oxford-variadic-comma.html <
> https://eisenwave.github.io/cpp-proposals/oxford-variadic-comma.html>
> >
> > IMHO it's unfortunate that the grammar for /parameter-declaration-clause
> <https://eel.is/c++draft/dcl.fct#nt:parameter-declaration-clause>/ is so
> mixed up at the moment.[...]
> > It would be so much cleaner to rewrite the grammar as
> > parameter-declaration-clause:
> > ...
> > parameter-declaration-list
> > parameter-declaration-list , ...
> > parameter-declaration-list ...
> > where the fourth production is deprecated and the first three are not.
> [...]
>
> If the proposal would refactor the grammar to more clearly expose the
> deprecated
> case, I think that would be totally fine. Since the blast radius of
> grammar
> changes is quite large, I wouldn't entertain such as an editorial issue
> (which does not have CWG oversight). [...]
>

Actually, I think my refactoring might have been totally wrong. (And I'm
glad Jens said it's not editorial, because even if it's not wrong, it's
still way worse than I'd thought at first.) All this talk about the
"hexadot" — which, as jwakely indicated, has now been "meme-coded" into *real
production codebases*, ugh — has made me realize that what the current
first grammar production actually allows is

   void f()
   void f(int)
   void f(int x)
   void f(...)
   void f(int x ...) // deprecated, equivalent to f(int,...)
   void f(auto x ...) // deprecated, equivalent to f(auto,...)
   void f(int ...) // deprecated, triggers [dcl.fct]/26
<https://eel.is/c++draft/dcl.fct#26>, equivalent to f(int,...)
   void f(auto ...)
   void f(int ...xs) // ill-formed today
   void f(auto ...xs)
   void f(int ...xs ...) // ill-formed and also deprecated
   void f(auto ...xs ...) // deprecated, equivalent to f(auto...,...)
   void f(int ... ...) // ill-formed and also deprecated
   void f(auto ... ...) // deprecated, equivalent to f(auto...,...)

I think the paper's wording is still correct, but the Annex D example needs
to be extended to cover the "hexadot" cases:

    void a(auto...); // OK
    void b(auto, ...); // OK


* void c(auto... ...); // deprecated void d(auto..., ...); // OK*
void f(...); // OK
    void g(int...); // deprecated
    void h(int, ...); // OK
    void k(int x...); // deprecated
    void l(int x, ...); // OK
* void m(auto... xs...); // deprecated*
* void n(auto... xs, ...); // OK*

*Jan,* I think the proposal ought to be clearer about what "deprecated"
actually means — e.g., maybe add a Tony Table of "Today's meaning /
Deprecated (Y/N)? / Tomorrow's meaning." The proposal currently says, "If
the variadic comma was made mandatory, this rule would simply be removed
and the rest left intact." But it's not clear to me that the outcomes will
be legible to working programmers. I think these are the most (only?)
important rows of that table:
    int f(...); // Today: ellipsis parameter. Deprecated? No. Tomorrow's
meaning: ellipsis parameter.
    int f(auto ...); // Today: parameter pack. Deprecated? No. Tomorrow's
meaning: parameter pack.
    int f(int ...); // Today: ellipsis parameter. Deprecated? Yes.
Tomorrow's meaning: parameter pack.
    int f(auto xs...); // Today: ellipsis parameter. Deprecated? Yes.
Tomorrow's meaning: ill-formed.
    int f(auto... ...); // Today: parameter pack followed by ellipsis
parameter. Deprecated? Yes. Tomorrow's meaning: ill-formed.

*Jonathan,* would you be willing to stop using the meme-stock hexadot in
libstdc++'s headers? I think every year it remains in those headers is a
year we can't remove it from the standard.

–Arthur