copy-list-initialization and converting constructors [over.match.list]


I have a doubt about this paragraph of [over.match.list] …

“If the initializer list has no elements and T has a default constructor, the first phase is omitted. In copy-listinitialization,
if an explicit constructor is chosen, the initialization is ill-formed. [ Note: This differs from
other situations (,, where only converting constructors are considered for copy-initialization.
This restriction only applies if this initialization is part of the final result of overload resolution. —end note ]”

According to the above, what should be the result of compiling the following code?

// Begin code

struct like_std_string
like_std_string(InputIterator begin, InputIterator end); // This is a converting constructor.

struct my_string
explicit my_string(InputIterator begin, InputIterator end); // This is not a converting constructor.

void foo( like_std_string );
void foo( std::pair<std::string, std::string> );

void bar( my_string );
void bar( std::pair<std::string, std::string> );

int main( /* int argc, char* argv */ )
foo( {“k0”, “v0”} ); // ambiguous in Clang (3.1) and GCC (4.7.1). OK, I think.
bar( {“k0”, “v0”} ); // Not ambiguous in Clang. Ambiguous in GCC. Ambiguous to the Standard? I think should not be ambiguous.

return 0;

// End code

GCC and Clang disagree on the interpretation of Standard (?).

Is GCC wrong? Is Clang wrong? Is the Standard confusing?

I don’t understand what is the intent of this paragraph (I think it would be good to add some examples to the paragraph.)
The final wording of “Initializer list” belongs to n2672 paper, which is based on n2640 paper.

I think that n2640 mentions some important points about explicit, converting constructors, and initializer-lists.
I believe that only converting constructors should be considered for copy-initialization.
I don’t know what were the reasons for considering all constructors, including the explicit constructors.

(I have no access to the mailing-list to find out what happened)

Thanks and Regards,
Fernando Pelliccioni.

Did you try this with the most recent SVN version? I’m pretty sure this was reported as a bug and fixed before the 3.1 branch even.


I tested with 3.1 (trunk 155038)

Updating and re-testing.

Same effect on

$ clang++ --version
clang version 3.2 (trunk 157183)
Target: i386-pc-linux-gnu
Thread model: posix

I don’t know if it is a bug ( I wish not )


I also see this on ToT. It is a bug: the standard seems clear that ‘explicit’ does not affect the overload selected by overload resolution for list-initialization, and only acts to make the resulting call ill-formed.

I know that Clang doesn’t conform the Standard (in that paragraph) but …
…thinking…, Is it a issue of the Standard?

I will ask this question in the right place.

The bug has not been resolved.
Tested at …

clang version 3.2 (trunk 159239)

However, I think it’s a standard core language issue.