Any difference between copy-list-initialization and traditional copy-initialization?

12
votes

Except for supporting multiple arguments, disallowing narrowing conversion, matching constructor taking std::initializer_list argument, what else is different for copy-list-initialization against traditional copy-initialization?

To be specific, assume there are two user-defined types, A and B:

class A {...};
class B {...};

B b;
A a1 = {b};
A a2 = b;

What kind of definition of A and B will make a difference on those two forms of initialization? e.g. Is there a certain definition of A and B that will make one of the initialization legal but the other illegal, or both legal but with different semantics, or both illegal with different causes?

(Assume A doesn't have a constructor taking std::initializer_list argument.)

EDIT: Adding a link to a somewhat related question of mine: What is the supposed behavior of copy-list-initialization in the case of an initializer with a conversion operator?

2
c++c++11

2 Answers

14
votes

Copy-initialization always considers availability of copy constructors, while copy-list-initialization doesn't.

class B {};
struct A 
{
  A(B const&) {}
  A(A const&) = delete;
};

B b;
A a1 = {b};  // this compiles
A a2 = b;    // this doesn't because of deleted copy-ctor

This is because copy-list-initialization is identical to direct-list-initialization except in one situation - had A(B const&) been explicit, the former would've failed, while the latter will work. 

class B {};
struct A 
{
  explicit A(B const&) {}
};


int main()
{
    B b;
    A a1{b};    // compiles
    A a2 = {b}; // doesn't compile because ctor is explicit
}
11
votes

Probably, the behaviour of the new copy-list-initialization was defined to be "good" and consistent, but the "weird" behaviour of old copy-initialization couldn't be changed because of backward compatibility.
As you can see the rules for list-initialization in this clause are identical for direct and copy forms.
The difference related to explicit is described only in the chapter on overload resolution. But for traditional initialization direct and copy forms are not identical.
The traditional and brace initializations are defined separately, so there's always a potential for some (probably unintended) subtle differences.

The differences I can see from the excerpts of the standard:

1. Already mentioned differences

  • narrowing conversions are disallowed
  • multiple arguments are possible

  • braced syntax prefers initializer-list constructors if they present: 

    struct A
{
    A(int i_) : i (i_) {}
    A(std::initializer_list<int> il) : i (*il.begin() + 1) {}
    int i;
}

A a1 = 5; // a1.i == 5
A a2 = {5}; // a2.i = 6


2. Different behaviour for aggregates

For aggregates you can't use braced copy-constructor, but can use traditional one. 

    struct Aggr
    {
        int i;
    };

    Aggr aggr;
    Aggr aggr1 = aggr; // OK
    Aggr aggr2 = {aggr}; // ill-formed


3. Different behaviour for reference initialization in presence of conversion operator

Brace initialization can't use operators of conversion to reference type 

struct S
{
    operator int&() { return some_global_int;}
};

int& iref1 = s; // OK
int& iref2 = {s}; // ill-formed


4. Some subtle differences in initialization of object of class type by object of other type

These difference are marked by [*] in the excerpts of the Standard at the end of this answer.

  • Old initialization uses notion of user-defined conversion sequences (and, particularly, requires availability of copy constructor, as was mentioned)
  • Brace initialization just performs overload resolution among applicable constructors, i.e. brace initialization can't use operators of conversion to class type

These differences are responsible for some not very obvious (for me) cases like 

struct Intermediate {};

struct S
{
    operator Intermediate() { return {}; }
    operator int() { return 10; }
};

struct S1
{
    S1(Intermediate) {}
};

S s;
Intermediate im1 = s; // OK
Intermediate im2 = {s}; // ill-formed
S1 s11 = s; // ill-formed
S1 s12 = {s}; // OK

// note: but brace initialization can use operator of conversion to int
int i1 = s; // OK
int i2 = {s}; // OK


5. Difference in overload resolution

  • Different treatment of explicit constructors

See 13.3.1.7 Initialization by list-initialization

In copy-list-initialization, if an explicit constructor is chosen, the initialization is ill-formed. [ Note: This differs from other situations (13.3.1.3, 13.3.1.4), where only converting constructors are considered for copy initialization. This restriction only applies if this initialization is part of the final result of overload resolution. — end note ]

If you can see more differences or somehow correct my answer (including grammar mistakes), please do.

Here are the relevant (but long) excerpts from the current draft of the C++ standard (I haven't found a way to hide them under spoiler):
All of them are located in the chapter 8.5 Initializers

8.5 Initializers

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

8.5.3 References ...

8.5.4 List-initialization

List-initialization of an object or reference of type T is defined as follows:

  • If T is an aggregate, aggregate initialization is performed (8.5.1).

  • Otherwise, if the initializer list has no elements and T is a class type with a default constructor, the object is value-initialized.

  • Otherwise, if T is a specialization of std::initializer_list<E>, a prvalue initializer_list object is constructed as described below and used to initialize the object according to the rules for initialization of an object from a class of the same type (8.5).

  • [*] Otherwise, if T is a class type, constructors are considered. The applicable constructors are enumerated and the best one is chosen through overload resolution (13.3, 13.3.1.7). If a narrowing conversion (see below) is required to convert any of the arguments, the program is ill-formed.

  • Otherwise, if the initializer list has a single element of type E and either T is not a reference type or its referenced type is reference-related to E, the object or reference is initialized from that element; if a narrowing conversion (see below) is required to convert the element to T, the program is ill-formed.

  • Otherwise, if T is a reference type, a prvalue temporary of the type referenced by T is copy-list-initialized or direct-list-initialized, depending on the kind of initialization for the reference, and the reference is bound to that temporary. [ Note: As usual, the binding will fail and the program is ill-formed if the reference type is an lvalue reference to a non-const type. — end note ]

  • Otherwise, if the initializer list has no elements, the object is value-initialized.

  • Otherwise, the program is ill-formed.