Почему auto x{3} выводит initializer_list?

Question

Я люблю auto в C++11. Это замечательно. Но у него есть одно несоответствие, которое действительно действует мне на нервы, потому что я постоянно спотыкаюсь об этом:

int i = 3;       // i is an int with value 3
int i = int{3};  // i is an int with value 3
int i(3);        // i is an int with value 3 (possibly narrowing, not in this case)
int i{3};        // i is an int with value 3

auto i = 3;      // i is an int with value 3
auto i = int{3}; // i is an int with value 3
auto i(3);       // i is an int with value 3
auto i{3};       // wtf, i is a std::initializer_list<int>?!

Это странное поведение сбивает с толку новичков и раздражает опытных пользователей - в C++ достаточно мало несоответствий и угловых случаев, о которых нужно помнить, как есть. Кто-нибудь может объяснить, почему комитет по стандартам решил ввести новый в этом случае?

Я мог бы понять это, если объявить переменную типа std::initializer_list было чем-то полезным или делалось часто, но по моему опыту это почти никогда не было преднамеренным - и в тех редких случаях, когда вы хотели это сделать, любой из

std::initializer_list<int> l{3};
auto l = std::initializer_list<int>{3};
auto l = {3}; // No need to specify the type

будет работать просто отлично. Так в чем же причина особого случая auto x{i}?

Answer 1

Короче говоря:

• выражение инициализатора в скобках {} не имеет типа сам по себе
• auto должен выводить информацию о типе
• int{3} очевидно означает "создать int var со значением, взятым из списка инициализаторов ", таким образом, его тип просто int и может быть использован в любом более широком контексте (int i = int{3} будет работать и auto i = int{3} может вывести тип, потому что правая сторона явно имеет тип int)
• {3} сам по себе не имеет типа (это не может быть int потому что это не значение, а список инициализатора), так auto не будет работать - но, потому что комитет посчитал, что auto в этом случае все еще должно работать, они решили, что "лучший" тип для (да, по типу не типизированного) списка инициализатора будет... std::initializer_list Как вы уже, наверное, догадались.

Но, как вы указали, это сделало все поведение auto довольно семантически противоречивый. Вот почему были предложены изменения, а именно N3681, N3912 и N3922, представленные в комитет. Прежнее предложение было отклонено как FI3 из-за отсутствия консенсуса в комитете по этому вопросу, http://isocpp.org/files/papers/n3852.html, текущий (N3922) был принят ок. Первый квартал 2015 года;

Вы можете предположить, что совместимые со стандартами компиляторы ¹ с новейшей поддержкой C++ ² либо уже имеют новую, более разумную семантику, либо вскоре ее установят.

Комитет по стандартизации признал проблему, приняв N3922 в проект C++17.

- так что это

auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
auto x2 = { 1, 2.0 }; // error: cannot deduce element type
auto x3{ 1, 2 }; // error: not a single element
auto x4 = { 3 }; // decltype(x4) is std::initializer_list<int>
auto x5{ 3 }; // decltype(x5) is int

сейчас, к лучшему или к худшему.

_{дальнейшее чтение:}

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3681.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3912.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html

http://scottmeyers.blogspot.com/2014/03/if-braced-initializers-have-no-type-why.html

http://herbsutter.com/2014/11/24/updates-to-my-trip-report/

---

¹ GCC 5.1 (и выше), очевидно, использует N3922 даже в режиме C++11/C++14

² лязга 3.8, с оговоркой

Это обратно несовместимое изменение, которое применяется ко всем языковым версиям, которые позволяют вычитать тип из auto (согласно запросу комитета C++).