On 2 February 2014 21:07, Michael Powell wrote: > Hmm, so it seems MSVC isn't the only compiler with initializer list issues... ? G++ apparently has a bug in this area, but otherwise has excellent support for initializer lists. > My question is, to borrow a coined phrase, how do you "reason" about > this one? Which version of "f" would you expect to be called, It's not possibly to implicitly create a bar object form an int, because it's constructor is explicit. Therefore f(foo) is the only viable overload. > and why > would that be practical anyway, potentially confusing foo with bar? That's not really relevant, the compiler has to do what the language standard says, whether the code is useful or not. > So in other words, my question would be, is this truly a bug? It's a bug. Argument passing is copy-initialization ([dcl.init]/14), so f({0}) is copy-list-initialization, and so if overload resolution chooses an explicit constructor it's ill-formed ([over.match.list]/1)