dmd 1.070 and 2.055 release

[Ali Çehreli]

On Sun, 11 Sep 2011 15:08:20 -0700, Walter Bright wrote:

> On 9/11/2011 2:18 PM, Jonathan M Davis wrote:
>> isn't legal when S is a struct whose default constructor has been
>> disabled. Actually, what worries me is what happens when you try and
>> use S.init (I haven't tried it, so I don't know what happens). S.init
>> has effectively been made non-existent by this @disable this(); but
>> there's plenty of templated code out there that would try and use the
>> init value for checking stuff. I would assume that such code would
>> fail, but I don't know. Assuming that such code can actually work with
>> a struct whose default initializer has been disabled, such template
>> constraints are going to have to be written differently now.
> 
> Using S.init is still fine. The idea is to force the use of explicit
> initialization.

The problem is, the disabled default constructor of a *member* is making 
a wrapper class's constructor to be disabled as well:

struct S
{
    @disable this();
    this(int x)
    {
    }
}

class C
{
    S s = S.init;

    this()
    {
        this.s = S.init;
    }
}

void main()
{
    auto c = new C;
}

Error: default construction is disabled for type C

C should be allowed to have a default constructor because it plays nice 
and does use explicit construction of S. Even if you use S.this(int) in 
C, it still doesn't work. I think this is at least limiting and very 
likely a bug.

Ali