CWG3228 [dcl.init] Empty initializers are referred to grammatically, which does not include empty packs

[Halalaluyafail3]

Full name of submitter (unless configured in github; will be published with the issue): Jay Ghiron

Reference (section label): [dcl.init]

Issue description:

Consider the following:

void foo(auto...x){
    int y[]{x...};
}
void bar(auto...z){
    int w(z...);
}
int main(){
    foo();
    bar();
}

For the invocation of foo, [dcl.init.aggr]/11 has the following text:

An array of unknown bound shall not be initialized with an empty braced-init-list {}.

(footnote) The syntax provides for empty braced-init-lists, but nonetheless C++ does not have zero length arrays.

Existing compilers reject this invocation of foo because it tries to create an array of length zero, but the wording appears to be a purely syntactic restriction that does not forbid one or more initializer clauses that are all empty pack expansions. Note that the footnote emphasizes this by directly talking about the syntax. For the invocation of bar, [dcl.init.general]/15.4 has the following text:

If the initializer is (), the object is value-initialized.

(note) Since () is not permitted by the syntax for initializer,

X a();

is not the declaration of an object of class X, but the declaration of a function taking no arguments and returning an X. The form () can appear in certain other initialization contexts ([expr.new], [expr.type.conv], [class.base.init]).

Existing compilers do value initialize here, but the wording appears to be a purely syntactic condition that does not include one or more initializer clauses that are all empty pack expansions. The following note also emphasizes this by talking about the syntax too.

Suggested resolution:

Modify [dcl.init.general]/15.4:

If the initializer is ()of the form (expression-list_opt) and the initializer contains zero elements, the object is value-initialized.

Modify [dcl.init.aggr]/11:

An array of unknown bound shall not be initialized with an empty braced-init-list {}that contains zero elements.

Value initialization using parentheses with an array of unknown bound appears to be forbidden by the type never being completed, perhaps wording should be added to make it more clear. Unrelated to this issue, but there also appears to be implementation divergence about whether new int[]{} and new int[]() should be valid.

[jensmaurer]

CWG3228

[Halalaluyafail3]

The wording "or is an expansion of an empty pack" sounds like it would not include expansions of multiple empty packs (or of the same empty pack multiple times).

[t3nsor]

The wording "or is an expansion of an empty pack" sounds like it would not include expansions of multiple empty packs (or of the same empty pack multiple times).

It feels like the optimal wording strategy is to introduce a prose term analogous to "argument". The compiler parses the expression-list in a call expression, expands any packs, and the result is some number of arguments, the number of which we could in principle talk about. We should be able to do the same thing for the expression-list in a direct-initialization.

[jensmaurer]

In the case of multiple packs, the arities must agree, so "an" can pick any of those in view. If you expand the same pack multiple times, it's still the same pack, so "an" works, I think.

[jensmaurer]

@t3nsor , I generally agree, but I guess those examples are not the only cases where we have less than stellar wording around packs (base classes come to mind). So, a somewhat surgical less-obviously-grammatical rephrasing seems most efficient at this time.

While I'm here: Which compiler gets this wrong currently?

[Halalaluyafail3]

In the case of multiple packs, the arities must agree, so "an" can pick any of those in view. If you expand the same pack multiple times, it's still the same pack, so "an" works, I think.

I meant:

void baz(auto...a,auto...b){
    int x[4](a...,b...);
}

The wording should handle the case of when these are both empty.

[jensmaurer]

I've updated CWG3228.