Daniel James wrote:

Does anyone know which compiler is doing the right thing? I assume it's a Visual C++ bug, but I'm not sure.

I was so intrigued by string{"a","b"} (*) that I asked on c++std-core, and while so far there's been no authoritative answer as to whether VC++ is right or not (too early for that), Johannes Schaub has kindly pointed me to http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2238 and http://stackoverflow.com/q/14587436/34509 which deal with similar issues. (*) For the interested, this appears to call the InputIterator constructor, with predictable results.

On 19 October 2013 22:35, Peter Dimov wrote:

...

I was so intrigued by string{"a","b"} (*) that I asked on c++std-core, and

while so far there's been no authoritative answer as to whether VC++ is right or not...

Johannes Schaub again kindly points us out to 13.3.3.2/3 last bullet:

— List-initialization sequence L1 is a better conversion sequence than list-initialization sequence L2 if L1 converts to std::initializer_list<X> for some X and L2 does not.

which means that g++ and clang are right and VC++ is wrong in this specific case.

Thanks, I'll try to work round it later this week.

On 5 November 2013 11:45, Joaquin M Lopez Munoz wrote:

Inspecting the log seems like you tried something and then reverted the commit. Didn't it work or did you just prefer to leave the VC bug exposed in wait for it to be fixed by MS themselves?

It didn't work. I don't have access to the compiler so I was just guessing. I also had made a mistake configuring boost build, so when I thought I was testing with gcc 4.8 in C++11 mode, I wasn't. So I made a bit of a mess and felt it was better left until later. There were already enough problems with the compiler. My basic idea is to do something like the following and hope that it's possible to make the template overload match where appropriate. Might also need to use enable_if to prevent some incorrect matches. But even if I could get it to work, it could be very fragile. Presumably this bug will also affect the standard containers as well, so maybe it's not something worth fixing. At least it's a compile error, and not silently picking the wrong overload. #include #include <string> #include <iostream> template <typename T> struct container { void insert(T const& x) { std::cout << "1" << std::endl; } void insert(std::initializer_list<T> x) { std::cout << "2" << std::endl; } template <typename T1> void insert(std::initializer_list<T1> x) { std::cout << "3" << std::endl; } }; int main() { containerstd::string c; std::cout << "String literal:\n"; c.insert("a"); std::cout << "std::string:\n"; c.insert(std::string("a")); std::cout << "initializer list of std::string:\n"; c.insert({std::string("a"), std::string("b")}); std::cout << "initializer list of string literals:\n"; c.insert({"a"}); c.insert({"a", "b"}); c.insert({"a", "b", "c"}); }

On 5 November 2013 12:21, Joaquin M Lopez Munoz wrote:

This looks serious enough, and, fwiw, there's another library (mine) suffering from seemingly the same problem:

http://lists.boost.org/Archives/boost/2013/10/207529.php

Looks very similar. Also suggests I need to add some extra constructor tests.

I've googled a bit and the only relevant reference I found is

http://tinyurl.com/nq89kc2

which refers to a problem supposedly fixed in the final version of VS 2013.

I think that's a different issue. In that case it seems that the conversion didn't work properly. Our problem is that it isn't seeing list initialization as a better conversion than the others.

Maybe Stephan is reading this and can shed some light?

Since Peter brought it up on c++std-core I assume someone from the compiler team would have seen that. I don't particularly want to report a bug for a compiler I don't have, but since it was confirmed that the earlier test failed, I could post that.

On 5 November 2013 16:32, Stephan T. Lavavej wrote:

I need a self-contained repro in order to file a compiler bug. I am aware of DevDiv#796414 "Overloading op+=(char) and op+=(initializer_list<char>) should be unambiguous" which is still active.

This is the example from the start of the thread which was confirmed to fail on Visual C++. I don't know how to find out about "DevDiv#796414" so I don't know if it's the same issue. #include #include <string> template <typename T> struct thing { void insert(T const&) {} void insert(T&&) {} void insert(std::initializer_list<T>) {} }; int main() { thingstd::string x; x.insert("a"); x.insert({"a"}); x.insert({"a", "b"}); }

[Daniel James]

I don't know how to find out about "DevDiv#796414" so I don't know if it's the same issue.

That's our internal database. (I cite bug numbers so if people ask me about them later I can look them up.)

This is the example from the start of the thread which was confirmed to fail on Visual C++.

Thanks, that's the same bug. Just in case, I've reduced your example and added it to the bug: C:\Temp>type purr.cpp #include struct string { string(const char *); template <typename InIt> string(InIt, InIt); }; void insert(const string&) { } void insert(std::initializer_list<string>) { } int main() { insert("a"); insert({ "b" }); insert({ "c", "d" }); } C:\Temp>cl /EHsc /nologo /W4 purr.cpp purr.cpp purr.cpp(13) : error C2668: 'insert' : ambiguous call to overloaded function purr.cpp(9): could be 'void insert(std::initializer_list<string>)' purr.cpp(8): or 'void insert(const string &)' while trying to match the argument list '(initializer-list)' purr.cpp(14) : error C2668: 'insert' : ambiguous call to overloaded function purr.cpp(9): could be 'void insert(std::initializer_list<string>)' purr.cpp(8): or 'void insert(const string &)' while trying to match the argument list '(initializer-list)' The bit of Standardese that we're not following is N3690 13.3.3.2 [over.ics.rank]/3: "List-initialization sequence L1 is a better conversion sequence than list-initialization sequence L2 if L1 converts to std::initializer_list<X> for some X and L2 does not." [Glen Fernandes]

Stephan, I seem to recall providing a slightly similar example that you added as repro to DevDiv#532674 when you renamed it "[Milan] initializer_list overloading" on 2012/11/29.

Half of that was the same bug (your complex<double> example). STL