initialization by "()"

(When) is it not covered by [dcl.init]/16?

The initialization that occurs in the forms

T x(a);
T x{a};

as well as in new expressions, static_­cast expressions, functional notation type conversions, mem-initializers, and the braced-init-list form of a condition is called direct-initialization.

Because "(a)" is different from "()". That's how I read it, even though I wish it was clearer.

But, if it was covered by that, then "For direct-initialization or default-initialization that is not in the context of copy-initialization ..." could be simplified to "For direct-initialization ..." straight away. And we could always use explicit constructors in the context of copy-list-initializations. Which seems... odd and against the intentions.

I mean, can the initializer "()" appear outside of new expressions, functional notation type conversions, or mem-initializers (i.e. the contexts listed after "as well as in")?

(I think T x(a); does not cover T x(); bacause it is not even a variable declaration.)

T x() can happen if a variadic template instantiates it from T x(args...);. It also appears in this context:

struct T { explicit T() { } };
T t = {};

Here, we are told by list-initialization clauses, to value-initialize t. And that means to default-initialize t. And that means to consider over.match.ctor with an initializer (). This initializer doesn't appear in code, but merely needed for the conditional verbiage in over.match.ctor.

Ok, now that you mention new-expressions, functional notation type conversions etc, I can see why it's deeply confusing. Yes, I agree, I think in some cases () is considered direct initialization, and in other cases, like my above examples, it is not.

And we use \grammarterm for "the initializer ()" in the description of default-initialization, but () doesn't match the initializer production at all.

Editorial meeting consensus: First issue, fixed by "For copy-initialization (including default initialization in the context of copy-initialization), the candidate functions are all the converting constructors of that class."
11.6p16 morph to bulleted list; fix "of the form" declaration-lookalikes to instead inspect grammar non-terminals.