[cfe-dev] defaulted default constructor with initializer

[Richard Smith]

On Thu, Apr 16, 2015 at 11:33 PM, Kal <b17c0de at gmail.com> wrote:

>  Am 17.04.15 um 01:48 schrieb Richard Smith:
>
>  On Thu, Apr 16, 2015 at 10:16 AM, Kal <b17c0de at gmail.com> wrote:
>
>>  Consider this code:
>>
>> class A {
>> public:
>>   struct I {
>>     int i = 0;
>>   };
>>   A(I i = {}) {}
>> };
>>
>> With clang 3.6 this doesn't compile:
>> 4 : error: cannot use defaulted default constructor of 'I' within 'A'
>> outside of member functions because 'i' has an initializer
>>
>> But if I change the code to
>>
>> class A {
>> public:
>>   struct I {
>>     int i = 0;
>>     I() {}
>>   };
>>   A(I i = {}) {}
>> };
>>
>> then the code compiles. Why is this so? Aren't these equivalent?
>>
>
>  They're not equivalent. The implicit constructor for A::I also has a
> deduced exception specification, and computing that exception specification
> requires the initializer for 'A::i' to have already been parsed.
>
> You mean initializer for 'A::I' to have already been parsed? But hasn't
> the entire class definition for A::I and its initializers already been
> parsed before A::A?
>

The exception specification for I::I is needed when parsing the default
argument for A::A(I). The C++ standard does not say which order the "when
the class is complete" elements are parsed; Clang handles them in this
order:

 1) attributes (thread safety attributes in particular)
 2) default arguments and exception specifications
 3) default member initializers
 4) function bodies

You can swap some of these around (or handle the delayed parts in purely
lexical order), but doing so just changes which set of programs you reject.
We handle (3) after (2) because it's unusual for a default argument or
exception specification to need a default constructor for the current class
(or a nested class). The best way to write portable code is to ensure that
nothing in (2) or (3) depends on anything in (2), (3), or (4).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150416/95bcfb0c/attachment.html>