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

[Fernando Pelliccioni]

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 )

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