¿Por qué es mejor la inicialización de listas (usando llaves) que las alternativas?

MyClass a1 {a};     // clearer and less error-prone than the other three
MyClass a2 = {a};
MyClass a3 = a;
MyClass a4(a);

¿Por qué?

No pude encontrar una respuesta en SO, así que déjame responder mi propia pregunta.

Básicamente copiando y pegando de "The C ++ Programming Language 4th Edition" de Bjarne Stroustrup :

La inicialización de la lista no permite el estrechamiento (§iso.8.5.4). Es decir:

• Un entero no se puede convertir a otro entero que no pueda mantener su valor. Por ejemplo, char to int está permitido, pero no int to char.
• Un valor de punto flotante no se puede convertir a otro tipo de punto flotante que no pueda contener su valor. Por ejemplo, se permite flotar a doble, pero no doble a flotar.
• Un valor de punto flotante no se puede convertir a un tipo entero.
• Un valor entero no se puede convertir a un tipo de punto flotante.

Ejemplo:

void fun(double val, int val2) {

    int x2 = val; // if val==7.9, x2 becomes 7 (bad)

    char c2 = val2; // if val2==1025, c2 becomes 1 (bad)

    int x3 {val}; // error: possible truncation (good)

    char c3 {val2}; // error: possible narrowing (good)

    char c4 {24}; // OK: 24 can be represented exactly as a char (good)

    char c5 {264}; // error (assuming 8-bit chars): 264 cannot be 
                   // represented as a char (good)

    int x4 {2.0}; // error: no double to int value conversion (good)

}

La única situación en la que se prefiere = sobre {} es cuando se usa la autopalabra clave para obtener el tipo determinado por el inicializador.

Ejemplo:

auto z1 {99};   // z1 is an int
auto z2 = {99}; // z2 is std::initializer_list<int>
auto z3 = 99;   // z3 is an int

Conclusión

Prefiere la inicialización {} sobre las alternativas a menos que tengas una buena razón para no hacerlo.

Ya hay excelentes respuestas sobre las ventajas de usar la inicialización de la lista, sin embargo, mi regla general personal es NO usar llaves siempre que sea posible, sino que dependerá del significado conceptual:

• Si el objeto que estoy creando conceptualmente contiene los valores que paso en el constructor (por ejemplo, contenedores, estructuras de POD, atómicos, punteros inteligentes, etc.), entonces estoy usando llaves.
• Si el constructor se parece a una llamada de función normal (realiza algunas operaciones más o menos complejas que están parametrizadas por los argumentos), entonces estoy usando la sintaxis de llamada de función normal.
• Para la inicialización predeterminada, siempre uso llaves.
  Por un lado, de esa manera siempre estoy seguro de que el objeto se inicializa independientemente de si es, por ejemplo, una clase "real" con un constructor predeterminado que se llamaría de todos modos o un tipo incorporado / POD. En segundo lugar, es, en la mayoría de los casos, coherente con la primera regla, ya que un objeto inicializado predeterminado a menudo representa un objeto "vacío".

En mi experiencia, este conjunto de reglas se puede aplicar de manera mucho más consistente que el uso de llaves por defecto, pero tener que recordar explícitamente todas las excepciones cuando no se pueden usar o tienen un significado diferente que la sintaxis de llamada de función "normal" con paréntesis (Llama a una sobrecarga diferente).

Por ejemplo, encaja perfectamente con tipos de biblioteca estándar como std::vector:

vector<int> a{10,20};   //Curly braces -> fills the vector with the arguments

vector<int> b(10,20);   //Parentheses -> uses arguments to parametrize some functionality,                          
vector<int> c(it1,it2); //like filling the vector with 10 integers or copying a range.

vector<int> d{};      //empty braces -> default constructs vector, which is equivalent
                      //to a vector that is filled with zero elements

Hay MUCHAS razones para usar la inicialización de llaves, pero debe tener en cuenta que el initializer_list<>constructor es preferido a los otros constructores , la excepción es el constructor predeterminado. Esto conduce a problemas con los constructores y las plantillas, donde el Tconstructor de tipos puede ser una lista de inicializadores o un viejo ctor simple.

struct Foo {
    Foo() {}

    Foo(std::initializer_list<Foo>) {
        std::cout << "initializer list" << std::endl;
    }

    Foo(const Foo&) {
        std::cout << "copy ctor" << std::endl;
    }
};

int main() {
    Foo a;
    Foo b(a); // copy ctor
    Foo c{a}; // copy ctor (init. list element) + initializer list!!!
}

Suponiendo que no encuentre tales clases, hay pocas razones para no usar la lista de inicializadores.

Solo es más seguro siempre que no construyas con -Ninguna reducción como lo hace Google en Chromium. Si lo hace, entonces es MENOS seguro. Sin esa bandera, los únicos casos inseguros serán corregidos por C ++ 20.

Nota: A) Las llaves son más seguras porque no permiten el estrechamiento. B) Los brackers rizados son menos seguros porque pueden omitir constructores privados o eliminados, y llamar implícitamente a constructores marcados explícitamente.

Esos dos combinados significan que son más seguros si lo que hay dentro son constantes primitivas, pero menos seguros si son objetos (aunque se arreglan en C ++ 20)