Uniform initialization is an important and useful C++11 feature. However, you can't just use {} everywhere since:
std::vector<int> a(10, 0); // 10 elements of value zero
std::vector<int> b({10, 0}); // 2 elements of value 10 and 0 respectively
std::vector<int> c{10, 0}; // 2 elements of value 10 and 0 respectively
std::vector<int> d = {10, 0}; // 2 elements of value 10 and 0 respectively
auto e(0); // deduced type is int
auto f = 0; // deduced type is int
auto g{0}; // deduced type is std::initializer_list<int>
auto h = {0}; // deduced type is std::initializer_list<int>
Noting that aggregate initialization on e.g. std::arrays requires the use of {{}}, it seems to me that the whole problem with which vector constructor will be selected could have been avoided by requiring a {{}} to call constructors taking a std::initializer_list:
std::vector<int> i{10, 0}; // 10 elements of value zero
std::vector<int> j{{10, 0}}; // 2 elements of value 10 and 0 respectively
std::vector<int> k = {10, 0}; // 2 elements of value 10 and 0 respectively
auto l{0}; // deduced type is int
auto m{{0}}; // deduced type is std::initializer_list<int>
auto n = {0}; // deduced type is std::initializer_list<int>
I'm sure this was discussed, so what were the reasons against this? A quote/link from a standard proposal is preferred as answer.
Update. — There is a point in N2532 that states:
(3) The likely nasty ambiguity cases occur only for short initializer lists [...]
(5) Why should the language rules force programmers who wants terseness
and ambiguity control (for perfectly good reasons) to write more to
please programmers who prefer (for perfectly good reasons) to be more
explicit – and can be?
[...]
Assume that a programmer expects f(X) to be called. How might a f(Y)
“hijack” a call?
(4) Assume that X has no initializer-list constructor, but Y does. In
this case, the priority given to initializer-list constructors favor
the hijacker (remember we assumed that the programmer somehow
expected f(X) to be called). This is analogous to someone expecting
f(y) to invoke f(X) using a user-defined conversion and someone comes
along with an f(Y) that matches exactly. I think it would be fair to
expect that someone who uses {…} will remember the possibility of
initializer-lists constructors. [emphasis mine]
I guess the key lies in the can be, which means you don't have to use uniform initialization. Using {} correctly is hard since:
you not only have to check for the constructor you want to call but also for any constructor taking an initializer_list that might win (and probably will) over it;
if you write code using {} and someone in the future adds an std::initializer_list constructor your code might break and do so silently.
Even if you have a class A with the constructors A(int, bool) and A(std::initializer_list<double>), the latter will be selected over the former for A a{0, false}; (which IMO is nuts), so I find it really hard to use uniform initialization on classes that have or might have (crystal ball superpowers required) initializer_list constructors.
The fact that your code can silently break worries me a lot.
See Question&Answers more detail:
os 
