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 :)
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
