On Monday, September 12, 2011 21:02:52 Timon Gehr wrote:
> On 09/12/2011 05:10 PM, Steven Schveighoffer wrote:
> > On Mon, 12 Sep 2011 10:50:49 -0400, Simen Kjaeraas
> > 
> > <simen.kjaras@gmail.com> wrote:
> >> On Mon, 12 Sep 2011 16:43:36 +0200, Steven Schveighoffer
> >> 
> >> <schveiguy@yahoo.com> wrote:
> >>> While I agree a nested "@disable this" struct inside a struct should disable default construction of the outer struct, a class *requires* initialization, and a default constructor is called explicitly (and can be defined!) We are talking two different worlds here.
> >>> 
> >>> I think the above should be accepted. I'm not sure how feasible it is, since it requires code path analysis.
> >> 
> >> What do you mean analysis? What's needed is checking 'did this class explicitly implement a default ctor?'. Te other test ('is the struct properly initialized?' is already performed for other constructors, so should pose no huge impediment.
> > 
> > I mean the compiler has to verify a constructor is called for the member struct in the class constructor.
> > 
> > You also must define a constructor of some kind (does not have to be a no-arg ctor), because the compiler generated default constructor cannot call the default constructor of the struct.
> > 
> > Maybe it's easy, but I have no idea, hence "I'm not sure" :)
> > 
> > -Steve
> 
> The compiler already checks that for non-default class constructors, so the change would probably be very easy to carry out.

I think that the problem is that the compiler needs to guarantee that the constructor actually initializes the member variable which can't be default constructed. But since it already has to do that with immutable constructors, that's probably not all that diffucult a change either.

- Jonathan M Davis

On 09/13/2011 12:09 AM, Jonathan M Davis wrote:
> On Monday, September 12, 2011 21:02:52 Timon Gehr wrote:
>> On 09/12/2011 05:10 PM, Steven Schveighoffer wrote:
>>> On Mon, 12 Sep 2011 10:50:49 -0400, Simen Kjaeraas
>>>
>>> <simen.kjaras@gmail.com>  wrote:
>>>> On Mon, 12 Sep 2011 16:43:36 +0200, Steven Schveighoffer
>>>>
>>>> <schveiguy@yahoo.com>  wrote:
>>>>> While I agree a nested "@disable this" struct inside a struct should
>>>>> disable default construction of the outer struct, a class *requires*
>>>>> initialization, and a default constructor is called explicitly (and
>>>>> can be defined!) We are talking two different worlds here.
>>>>>
>>>>> I think the above should be accepted. I'm not sure how feasible it
>>>>> is, since it requires code path analysis.
>>>>
>>>> What do you mean analysis? What's needed is checking 'did this class
>>>> explicitly implement a default ctor?'. Te other test ('is the struct
>>>> properly initialized?' is already performed for other constructors,
>>>> so should pose no huge impediment.
>>>
>>> I mean the compiler has to verify a constructor is called for the member
>>> struct in the class constructor.
>>>
>>> You also must define a constructor of some kind (does not have to be a
>>> no-arg ctor), because the compiler generated default constructor cannot
>>> call the default constructor of the struct.
>>>
>>> Maybe it's easy, but I have no idea, hence "I'm not sure" :)
>>>
>>> -Steve
>>
>> The compiler already checks that for non-default class constructors, so
>> the change would probably be very easy to carry out.
>
> I think that the problem is that the compiler needs to guarantee that the
> constructor actually initializes the member variable which can't be default
> constructed. But since it already has to do that with immutable constructors,
> that's probably not all that diffucult a change either.
>
> - Jonathan M Davis

Yes, that is what I meant. It already does that:

struct S{
    this() @disable;
}

class C{
    S s;
    this(){} // Error: constructor tt.C.this field s must be initialized in constructor
}

The only thing that needs to be changed is that classes containing non-default-constructible uninitialized fields can be default constructed if they provide a default constructor.

On Mon, 12 Sep 2011 20:44:26 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> Yes, that is what I meant. It already does that:
>
> struct S{
>      this() @disable;
> }
>
> class C{
>      S s;
>      this(){} // Error: constructor tt.C.this field s must be initialized in constructor
> }
>
> The only thing that needs to be changed is that classes containing non-default-constructible uninitialized fields can be default constructed if they provide a default constructor.

Oh wow, this really is a no-brainer.  Walter?

At least there should be an enhancement report.

-Steve