On 09/08/2011 07:21 AM, Walter Bright wrote:
> By far, the most number of bug fixes ever!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.070.zip
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.055.zip

Thanks! I have written a program that runs about twice as fast as before when compiled with DMD 2.055. What improvement could cause this?

On 9/10/2011 2:48 PM, Timon Gehr wrote:
> On 09/08/2011 07:21 AM, Walter Bright wrote:
>> By far, the most number of bug fixes ever!
>>
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.070.zip
>>
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.055.zip
>
> Thanks! I have written a program that runs about twice as fast as before
> when compiled with DMD 2.055. What improvement could cause this?

The big ones I can think of off the top of my head are:

1.  std.algorithm.copy is now specialized for arrays and is 10-80 times faster.

2.  Associative arrays now use the new NO_INTERIOR GC attribute, which massively cuts down on false pointers and therefore GC times when using lots of AAs.

3.  If you're using std.parallelism, the implementations of amap and parallel foreach have been completely rewritten to be more efficient, using an obvious-in-hindsight pattern that I found while working on the upcoming std.parallel_algorithm.

These are at the front of my mind because they're changes that I implemented.  Given the massive number of bug fixes/improvements there are probably a lot more potential reasons than those listed above.

On 09/08/2011 08:21 AM, Walter Bright wrote:
> By far, the most number of bug fixes ever!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.070.zip
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.055.zip

This test case

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

class C
{
    S s;
    this()
    {
        s = S(42);
    }
}

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

yields Error: default construction is disabled for type C

Is it a bug?

On 9/11/2011 9:08 AM, Max Samukha wrote:
> This test case
>
> struct S
> {
> @disable this();
> this(int x)
> {
> }
> }
>
> class C
> {
> S s;
> this()
> {
> s = S(42);
> }
> }
>
> void main()
> {
> auto c = new C;
> }
>
> yields Error: default construction is disabled for type C
>
> Is it a bug?

No, it's a feature!

On Sun, 11 Sep 2011 10:57:12 -0700, Walter Bright wrote:

> On 9/11/2011 9:08 AM, Max Samukha wrote:
>> This test case
>>
>> struct S
>> {
>> @disable this();
>> this(int x)
>> {
>> }
>> }
>>
>> class C
>> {
>> S s;
>> this()
>> {
>> s = S(42);
>> }
>> }
>>
>> void main()
>> {
>> auto c = new C;
>> }
>>
>> yields Error: default construction is disabled for type C
>>
>> Is it a bug?
> 
> No, it's a feature!

class C
{
    S s = S(0);      // <-- initial value provided

    this()
    {
        s = S(42);
    }
}

Since C doesn't use any default constructed S, I would expect at least the above to compile.

Could you please explain why the disabled default constructor of S affects C in that case (and even in Max's case).

Thank you,
Ali

On Sunday, September 11, 2011 18:57:03 Ali Çehreli wrote:
> On Sun, 11 Sep 2011 10:57:12 -0700, Walter Bright wrote:
> > On 9/11/2011 9:08 AM, Max Samukha wrote:
> >> This test case
> >> 
> >> struct S
> >> {
> >> @disable this();
> >> this(int x)
> >> {
> >> }
> >> }
> >> 
> >> class C
> >> {
> >> S s;
> >> this()
> >> {
> >> s = S(42);
> >> }
> >> }
> >> 
> >> void main()
> >> {
> >> auto c = new C;
> >> }
> >> 
> >> yields Error: default construction is disabled for type C
> >> 
> >> Is it a bug?
> > 
> > No, it's a feature!
> 
> class C
> {
>     S s = S(0);      // <-- initial value provided
> 
>     this()
>     {
>         s = S(42);
>     }
> }
> 
> Since C doesn't use any default constructed S, I would expect at least the above to compile.
> 
> Could you please explain why the disabled default constructor of S affects C in that case (and even in Max's case).

Your case should work (if it doesn't it's a bug, I believe), but Max's won't, because using

S s;

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.

- Jonathan M Davis

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.

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

On 9/11/2011 4:53 PM, Ali Çehreli wrote:
> The problem is, the disabled default constructor of a *member* is making
> a wrapper class's constructor to be disabled as well:

Right. It's infectious. This is deliberate.

> I think this is at least limiting and very
likely a bug.

It's deliberate. It's likely that we can find ways to loosen things up in the future, but the idea is to screw it down tight, first, instead of allowing big holes.

On 9/11/2011 9:07 PM, Walter Bright wrote:
> On 9/11/2011 4:53 PM, Ali Çehreli wrote:
>> The problem is, the disabled default constructor of a *member* is making
>> a wrapper class's constructor to be disabled as well:
>
> Right. It's infectious. This is deliberate.
>
>  > I think this is at least limiting and very
> likely a bug.
>
> It's deliberate. It's likely that we can find ways to loosen things up
> in the future, but the idea is to screw it down tight, first, instead of
> allowing big holes.

I've noticed that this is generally the philosophy when adding new features to D.  It's sometimes frustrating initially, but I'm starting to see how it pays off in the long run, e.g. with implicitly converting arrays returned from pure functions to immutable.