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

Мне нравится auto в С++ 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>?!

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

Я мог бы понять это, если объявление переменной типа 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}?

Ответы

Ответ 1

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

  • сжатое выражение инициализатора {} не имеет типа само по себе
  • auto должен выводить информацию о типе
  • int{3}, очевидно, означает "создать var int со значением, взятым из списка инициализаторов", поэтому его тип просто 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#FI3, current (N3922) получил принят ca. Q1 2015 года;

tl; dr вы можете предположить, что совместимые со стандартом компиляторы 1 с версия C + + с поддержкой С++ 2 либо уже имеет новую, более разумную семантику, либо будет иметь ее в ближайшее время.

Комитет по стандартизации признал эту проблему, приняв N3922 в проект С++ 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/

1 GCC 5.1 (& up) по-видимому, использует N3922 даже в режиме С++ 11/С++ 14

2 Clang 3.8, с оговоркой

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