[cfe-commits] r132661 - /cfe/trunk/test/SemaCXX/generalized-initializers.cpp

[Johannes Schaub (litb)]

Sebastian Redl wrote:

> 
> On 05.06.2011, at 15:03, Johannes Schaub (litb) wrote:
> 
>> Sebastian Redl wrote:
>> 
>>> Author: cornedbee
>>> Date: Sun Jun  5 07:23:08 2011
>>> New Revision: 132661
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=132661&view=rev
>>> Log:
>>> Expand on braced init list tests.
>>> 
>> ...
>>> namespace objects {
>>> 
>>> +  template <int N>
>>>   struct A {
>>> -    A();
>>> -    A(int, double);
>>> -    A(int, int);
>>> -    A(std::initializer_list<int>);
>>> -
>>> -    int operator[](A);
>>> +    A() { static_assert(N == 0, ""); }
>>> +    A(int, double) { static_assert(N == 1, ""); }
>>> +    A(int, int) { static_assert(N == 2, ""); }
>>> +    A(std::initializer_list<int>) { static_assert(N == 3, ""); }
>>>   };
>>> 
>>>   void initialization() {
>> ...
>>> +    { A<0> a{}; }
>>> +    { A<0> a = {}; }
>>> +    { A<1> a{1, 1.0}; }
>>> +    { A<1> a = {1, 1.0}; }
>>> +    { A<3> a{1, 2, 3, 4, 5, 6, 7, 8}; }
>>> +    { A<3> a = {1, 2, 3, 4, 5, 6, 7, 8}; }
>>> +    { A<3> a{1, 2, 3, 4, 5, 6, 7, 8}; }
>>> +    { A<3> a{1, 2}; }
>> 
>> This looks incorrect to me. All constructs, except the first two (which
>> does value-initialization and use the first constructor), use the last
>> constructor (the initializer list constructor).
> 
> But you can't create a std::initializer_list<int> from the init list {1,
> 1.0} because there's a narrowing conversion (double -> int) in there.
> 
> Hm, the standard isn't clear there IMO, because it doesn't say if the last
> constructor is viable for the init list {1, 1.0}. 

I agree with you. There are two paragraphs of particular interest here, I 
think: 13.3.3.1p2 and 13.3.3.1p9 . I believe both can be used to argue for 
opposite positions. p2 ends with "...  although an implicit conversion 
sequence can be defined ... the conversion from the argument to the 
parameter might still be ill-formed in the final analysis." and p9 ends with 
"... or the conversion is otherwise ill-formed, an implicit conversion 
sequence cannot be formed".

I wonder whether this can be clarified by erasing the second part of p9. The 
cases where that part intends to apply seem to be such cases like 
13.3.3.1.2p3:

"If the user-defined conversion is specified by a specialization of a 
conversion function template, the second standard conversion sequence shall 
have exact match rank."

One could word this like

"If the user-defined conversion is specified by a specialization of a 
conversion function template and the second standard conversion sequence 
does not have exact match rank, a conversion sequence cannot be formed."

A similar change was done already in DR #978 ("allowed" vs "considered"). 
Once these things are done, subclause 8.5 would only be needed to define 
what overload resolution context (13.3p2) is used, I believe. There may 
still be subtle things I'm missing that make the above impossible to work 
though. I've no idea :)