<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 18.05.2012, at 21:09, Fernando Pelliccioni wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,</div><div><br></div><div>I have a doubt about this paragraph of [over.match.list] ...</div><div><br></div><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:40px;border-top-style:none;border-right-style:none;border-bottom-style:none;border-left-style:none;border-width:initial;border-color:initial;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px">
<div>"If the initializer list has no elements and T has a default constructor, the first phase is omitted. In copy-listinitialization,</div><div>if an explicit constructor is chosen, the initialization is ill-formed. [ Note: This differs from</div>
<div>other situations (13.3.1.3, 13.3.1.4), where only converting constructors are considered for copy-initialization.</div><div>This restriction only applies if this initialization is part of the final result of overload resolution. —end note ]"</div>
</blockquote><div><br></div><div>According to the above, what should be the result of compiling the following code?</div><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:40px;border-top-style:none;border-right-style:none;border-bottom-style:none;border-left-style:none;border-width:initial;border-color:initial;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px"><div><br></div><div><font face="'courier new', monospace">struct my_string</font></div><div><font face="'courier new', monospace">{</font></div>
<div><font face="'courier new', monospace"> template<class InputIterator></font></div><div><font face="'courier new', monospace"> explicit my_string(InputIterator begin, InputIterator end); // This is *not* a converting constructor.</font></div>
<div><font face="'courier new', monospace">};</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">void foo( like_std_string );</font></div>
<div><font face="'courier new', monospace">void foo( std::pair<std::string, std::string> );</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">void bar( my_string );</font></div>
<div><font face="'courier new', monospace">void bar( std::pair<std::string, std::string> );</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">int main( /* int argc, char* argv[] */ )</font></div>
<div><font face="'courier new', monospace">{</font></div><div><font face="'courier new', monospace"> foo( {"k0", "v0"} );<span class="Apple-tab-span" style="white-space:pre"> </span>// ambiguous in Clang (3.1) and GCC (4.7.1). OK, I think.</font></div>
<div><font face="'courier new', monospace"> bar( {"k0", "v0"} );<span class="Apple-tab-span" style="white-space:pre"> </span>// *Not* ambiguous in Clang. Ambiguous in GCC. Ambiguous to the Standard? I think should *not* be ambiguous.</font></div>
</blockquote></blockquote>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.</div><div><br></div><div>Sebastian</div><br></body></html>