dmd 1.070 and 2.055 release

Timon Gehr timon.gehr at gmx.ch
Mon Sep 12 17:44:26 PDT 2011


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 at gmail.com>  wrote:
>>>> On Mon, 12 Sep 2011 16:43:36 +0200, Steven Schveighoffer
>>>>
>>>> <schveiguy at 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.








More information about the Digitalmars-d-announce mailing list