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

[Fernando Pelliccioni]

On Sun, May 20, 2012 at 3:19 PM, Sebastian Redl <
sebastian.redl at getdesigned.at> wrote:

>
> On 18.05.2012, at 21:09, Fernando Pelliccioni wrote:
>
> Hi,
>
> 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 (13.3.1.3, 13.3.1.4), 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?
>
>
> struct my_string
> {
>   template<class InputIterator>
>   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.
>
> 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.
>
> Sebastian
>
>
I tested with 3.1 (trunk 155038)

Updating and re-testing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120521/652add5f/attachment.html>