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

[Fernando Pelliccioni]

On Mon, May 21, 2012 at 3:30 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Mon, May 21, 2012 at 7:08 AM, Fernando Pelliccioni <
> fpelliccioni at gmail.com> wrote:
>
>> On Mon, May 21, 2012 at 9:22 AM, Fernando Pelliccioni <
>> fpelliccioni at gmail.com> wrote:
>>
>>> 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.
>>>
>>>
>>
>> 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.
>

The bug has not been resolved.
Tested at ...

clang version 3.2 (trunk 159239)

However, I think it's a standard core language issue.
https://groups.google.com/a/isocpp.org/d/topic/std-discussion/1J0Ik9Q1noU/discussion

Regards,
Fernando.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120626/85c55eef/attachment.html>