dmd 1.070 and 2.055 release

[Jonathan M Davis]

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