C++ Logo


Advanced search

Re: [std-proposals] The Oxford variadic comma

From: Jens Maurer <jens.maurer_at_[hidden]>
Date: Thu, 29 Feb 2024 22:06:58 +0100
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>
> remains valid and still points to the most recent version.
> 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 has:
> parameter-declaration-clause:
> parameter-declaration-list_opt ..._opt
> parameter-declaration-list , ...
> where the first production handles all of
> void f()
> void f(int)
> void f(int x)
> void f(...)
> void f(int...) // deprecated, equivalent to f(int,...)
> void f(auto...)
> void f(int x...) // deprecated, equivalent to f(int,...)
> void f(auto x...) // deprecated, equivalent to f(auto,...)
> 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.
> I admit I'm thinking about messy grammar mainly because of how much time I just put into studying the messy `friend` grammar and trying to disentangle it for "Variadic Friends." There's certainly a lot of precedent for the Committee's preferring "short and messy" over "long and clean," and concretely in this case, sadly, I think it would distract and slow down the paper if you asked to clean up the grammar at the same time.
> Hmm, I wonder whether cleaning up this particular grammar could be done editorially! That obviously wasn't on the table for `friend`, but might be doable for something this small and self-contained.

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).

I notice that the refactoring is missing the "empty" case (both opt's of the
original first production absent). We tend not to have "empty" productions,
at least not as an explicit "whitspace" production.
So, maybe the second of the new productions wants to have _opt.


Received on 2024-02-29 21:07:08