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

Richard Smith richard at metafoo.co.uk
Mon May 21 11:30:35 PDT 2012


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120521/19ebebf0/attachment.html>


More information about the cfe-dev mailing list