Is there a case missing in §8.5 p17 (semantics of initializers) of N3797?

Question

For the aggregate

struct S{int i, j;};

the declarations S s({1, 2}); and S s({1}); perform direct-initialization according to N3797 §8.5 p16:

The initialization that occurs in the forms

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

as well as in new expressions (5.3.4), static_cast expressions (5.2.9), functional notation type conversions (5.2.3), and base and member initializers (12.6.2) is called direct-initialization.

But §8.5 p17 doesn't seem to characterize them:

The semantics of initializers are as follows. The destination type is the type of the object or reference being initialized and the source type is the type of the initializer expression. If the initializer is not a single (possibly parenthesized) expression, the source type is not defined.

• If the initializer is a (non-parenthesized) braced-init-list, the object or reference is list-initialized (8.5.4).

• If the destination type is a reference type, see 8.5.3.

• If the destination type is an array of characters, an array of char16_t, an array of char32_t, or an array of wchar_t, and the initializer is a string literal, see 8.5.2.

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

• Otherwise, if the destination type is an array, the program is ill-formed.

• If the destination type is a (possibly cv-qualified) class type:

  • If the initialization is direct-initialization, or if it is copy-initialization where the cv-unqualified version of the source type is the same class as, or a derived class of, the class of the destination, constructors are considered. The applicable constructors are enumerated (13.3.1.3), and the best one is chosen through overload resolution (13.3). The constructor so selected is called to initialize the object, with the initializer expression or expression-list as its argument(s). If no constructor applies, or the overload resolution is ambiguous, the initialization is ill-formed.

  • Otherwise (i.e., for the remaining copy-initialization cases), user-defined conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof are enumerated as described in 13.3.1.4, and the best one is chosen through overload resolution (13.3). If the conversion cannot be done or is ambiguous, the initialization is ill-formed. The function selected is called with the initializer expression as its argument; if the function is a constructor, the call initializes a temporary of the cv-unqualified version of the destination type. The temporary is a prvalue. The result of the call (which is the temporary for the constructor case) is then used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization. In certain cases, an implementation is permitted to eliminate the copying inherent in this direct-initialization by constructing the intermediate result directly into the object being initialized; see 12.2, 12.8.

• Otherwise, if the source type is a (possibly cv-qualified) class type, conversion functions are considered. The applicable conversion functions are enumerated (13.3.1.5), and the best one is chosen through overload resolution (13.3). The user-defined conversion so selected is called to convert the initializer expression into the object being initialized. If the conversion cannot be done or is ambiguous, the initialization is ill-formed.

• Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. Standard conversions (Clause 4) will be used, if necessary, to convert the initializer expression to the cv-unqualified version of the destination type; no user-defined conversions are considered. If the conversion cannot be done, the initialization is ill-formed. [Note: An expression of type “cv1 T” can initialize an object of type “cv2 T” independently of the cv-qualifiers cv1 and cv2.

   int a;
   const int b = a;
   int c = b;
  

  — end note ]

The subject declarations, S s({1, 2}); and S s({1});:

• are not list-initialization, since each initializer is a parenthesized braced-init-list.
• the destination types are not references
• the destination types are not array of characters, in general.
• the initializers are not ()
• the destination types are not arrays.

Answer 1

This case is covered in the Standard: It's §8.5/17 6th bullet (emphasis mine):

If the destination type is a (possibly cv-qualified) class type:

• If the initialization is direct-initialization, or if it is copy-initialization where the cv-unqualified version of the source type is the same class as, or a derived class of, the class of the destination, constructors are considered. The applicable constructors are enumerated (13.3.1.3), and the best one is chosen through overload resolution (13.3). The constructor so selected is called to initialize the object, with the initializer expression or expression-list as its argument(s). If no constructor applies, or the overload resolution is ambiguous, the initialization is ill-formed.

Explanation: We first note that S is an aggregate (by §8.5.1/1). But an aggregate is also a class and hence has an implicitely declared defaulted copy/move constructor (by §12.8). Both constructors take one argument and hence are viable (by §13.3.2). Their signatures are as usual:

S(const S&) //copy
S(S&&)      //move

Now we have to determine the conversion sequence to convert the initializer-list {1,2} to the parameter types. §13.3.3.1.5/6 states:

Otherwise, if the parameter is a reference, see 13.3.3.1.4. [ Note: The rules in this section will apply for initializing the underlying temporary for the reference. —end note ]

Since the parameter types are references, §13.3.3.1.4/2 applies:

When a parameter of reference type is not bound directly to an argument expression, the conversion sequence is the one required to convert the argument expression to the underlying type of the reference according to 13.3.3.1. Conceptually, this conversion sequence corresponds to copy-initializing a temporary of the underlying type with the argument expression. Any difference in top-level cv-qualification is subsumed by the initialization itself and does not constitute a conversion.

Since S is an aggregate, we have to apply §13.3.3.1.5/5 to initialize this temporary object:

Otherwise, if the parameter has an aggregate type which can be initialized from the initializer list according to the rules for aggregate initialization (8.5.1), the implicit conversion sequence is a user-defined conversion sequence with the second standard conversion sequence an identity conversion.

Hence, we finally arrive at aggregate initialization of this temporary object. To determine which of these two constructors is the best viable function one has to consult §13.3.3.2 (which is left to the reader). Since the reference is bound to a temporary object the move constructor will actually be chosen.

Answer 2

The declarations S s({1, 2}); and S s({1}); perform direct-initialization according to N3797 §8.5 p16

Well, yes and no. In the first case, and similarly in the second, an S x-value object is constructed with {1, 2} and then passed to the implicitly-declared copy constructor of the s l-value.

This is not the case §8.5 p16 is discussing, because the initialization is not in the form:

S s(a);
S s{a};

unless the standard consider a to be anything. And even then, it's not part of the rest of the cases he defines right after (new, static_cast, etc..).

The subject declarations, S s({1, 2}); and S s({1}); are not list-initialization, since each initializer is a parenthesized braced-init-list.

The expressions {1, 2} and {1} are definitely list-initializations of temporary/expiring S objects.