Search code examples
c++c++11autoinitializer-listtype-deduction

Why does auto x{3} deduce an initializer_list?

I love auto in C++11. It's wonderful. But it has one inconsistency that really gets on my nerves, because I trip over it all the time:

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>?!

This strange behaviour is confusing for newcomers, and annoying for experienced users -- C++ has enough little inconsistencies and corner cases that one has to keep in mind as it is. Can anybody explain why standards committee decided to introduce a new one in this case?

I could understand it if declaring a variable of type std::initializer_list was something that was useful or done frequently, but in my experience it's almost never deliberate -- and in the rare cases where you did want to do it, any of

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

would work just fine. So what's the reason behind the special case for auto x{i}?

Solution

  • To make long story short:

    • a braced initializer expression {} has no type by itself
    • auto has to infer type information
    • int{3} obviously means "create an int var with value taken from initializer list", thus its type is just int and can be used in any wider context (int i = int{3} will work and auto i = int{3} can deduce type, because right side is obviously of type int)
    • {3} by itself has no type (it can't be int, because it's not a value but an initializer list), so auto wouldn't work — but, because committee considered that auto should still work in this case, they decided that the "best" type for (yeah, typeless by definition) initializer list would be... std::initializer_list, as you already probably guessed.

    But, as you pointed out, this made the whole behaviour of auto quite semantically inconsistent. That's why there were proposals to change it — namely N3681, N3912 and N3922 — submitted to the committee. Former proposal was REJECTED as FI3 due to no committee consensus on this matter, http://isocpp.org/files/papers/n3852.html#FI3 , current (N3922) got adopted ca. Q1 of 2015;

    tl;dr you may assume that standards-compliant compilers1 with bleeding-edge C++ support2 either have the new, more sane-ish semantics already in place, or will have it shortly.

    The Standardization Committee acknowledged the problem by adopting N3922 into draft C++17.

    — so it's 

    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

    now, for better or worse.

    further reading:

    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/

    1GCC 5.1 (& up) apparently uses N3922 even in C++11/C++14 mode

    2Clang 3.8, with the caveat

    This is a backwards-incompatible change that is applied to all language versions that allow type deduction from auto (per the request of the C++ committee).