Join the dmd beta mailing list to keep up with the betas. This one is pretty much good to go, unless something disastrous crops up.

http://ftp.digitalmars.com/dmd2beta.zip

Remaining regressions:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED 

On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
>
> Join the dmd beta mailing list to keep up with the betas. This one is pretty much good to go, unless something disastrous crops up.
>
> http://ftp.digitalmars.com/dmd2beta.zip

windows/bin/d.chm was generated using version 2.058, so there is
no some new information there.

On Wednesday, 22 May 2013 at 04:45:57 UTC, kdmult wrote:
> On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
>>
>> Join the dmd beta mailing list to keep up with the betas. This one is pretty much good to go, unless something disastrous crops up.
>>
>> http://ftp.digitalmars.com/dmd2beta.zip
>
> windows/bin/d.chm was generated using version 2.058, so there is
> no some new information there.

Actually, the documentation included into the archive is not up-to-date. It should be re-generated.

On 2013-05-21 22:36, Walter Bright wrote:
>
> Join the dmd beta mailing list to keep up with the betas. This one is
> pretty much good to go, unless something disastrous crops up.
>
> http://ftp.digitalmars.com/dmd2beta.zip

All directories have executable permission set.

-- 
/Jacob Carlborg

On 5/22/2013 11:55 PM, Jacob Carlborg wrote:
> On 2013-05-21 22:36, Walter Bright wrote:
>>
>> Join the dmd beta mailing list to keep up with the betas. This one is
>> pretty much good to go, unless something disastrous crops up.
>>
>> http://ftp.digitalmars.com/dmd2beta.zip
>
> All directories have executable permission set.

Is this the case with previous zips, or is it new for this one?

On 2013-05-23 09:08, Walter Bright wrote:

> Is this the case with previous zips, or is it new for this one?

Never mind. It was my tool. I tried a different one and it's not executable there.

-- 
/Jacob Carlborg

On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
>
> Join the dmd beta mailing list to keep up with the betas. This one is pretty much good to go, unless something disastrous crops up.
>
> http://ftp.digitalmars.com/dmd2beta.zip
>
> Remaining regressions:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

NO NO NO NO. I am violently opposed to this release.

This beta contains the worst language misfeature of all time. It's silently snuck in under the guise of a bugfix.


struct S
{
    const int x = 7;
    int y;
}

In previous releases, S.x was always 7.
But now, if you write

S s = S(5);

then x gets changed to 5.
This means that the const variable x has been initialized TWICE!

This new behaviour is counter-intuitive and introduces a horrible inconsistency.

This is totally different to what happens with module constructors (you get a compile error if you try to set a const global if it already has an initializer). Likewise, everywhere else in the language, when you see a const variable with an initializer, the initializer gives its value.


I think the only possible solution is to make it an error to provide a const or immutable member with an initializer.

If you are providing an initializer, you surely meant to make it 'static const', and that is certainly true of all existing usages of it.

As far as I can tell, this new feature exists only to create bugs. No use cases for it have been given. I cannot imagine a case where using this feature would not be a bug.


Please do not release this beta.

just filed a regression from 062 to 063:
http://d.puremagic.com/issues/show_bug.cgi?id=10141
it only affects error message though (giving a nonsensical error message).

Digression:
I used dustmite to reduce it (awesome tool) down to 6 files, but then had
to further manually reduce to 1 file.
I wish dustmite could be improved to 'run the last mile' by attempting to
merge files:
a.d:
import b;
b.d:
import c;
c.d:
//some stuff

dustmite should attempt to merge such files and reduce to:
a.d
// some stuff




On Tue, May 21, 2013 at 1:36 PM, Walter Bright <newshound2@digitalmars.com>wrote:

>
> Join the dmd beta mailing list to keep up with the betas. This one is pretty much good to go, unless something disastrous crops up.
>
> http://ftp.digitalmars.com/**dmd2beta.zip<http://ftp.digitalmars.com/dmd2beta.zip>
>
> Remaining regressions:
>
> http://d.puremagic.com/issues/**buglist.cgi?query_format=**
> advanced&bug_severity=**regression&bug_status=NEW&bug_**
> status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>
>

On Thursday, 23 May 2013 at 09:05:02 UTC, Don wrote:
> This means that the const variable x has been initialized TWICE!

That's no different from non-const members.

struct Foo { int x = 1; }
Foo f = Foo(2); // f.x is 2

The initialiser is a default value if you don't provide one in the constructor. If you don't mark a variable as static then it is not static and needs to be initialised like any other member variable.


> This new behaviour is counter-intuitive and introduces a horrible inconsistency.

It is exactly what happens in C++ and causes no confusion there.


> This is totally different to what happens with module constructors (you get a compile error if you try to set a const global if it already has an initializer).

In structs/classes, it is not an initialiser, it is a default value in case you don't provide a different value.


> As far as I can tell, this new feature exists only to create bugs. No use cases for it have been given. I cannot imagine a case where using this feature would not be a bug.

The use case is simple: to allow non-static const member variables.

On 05/23/13 11:05, Don wrote:
> On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
>>
>> Join the dmd beta mailing list to keep up with the betas. This one is pretty much good to go, unless something disastrous crops up.
>>
>> http://ftp.digitalmars.com/dmd2beta.zip
>>
>> Remaining regressions:
>>
>> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
> 
> NO NO NO NO. I am violently opposed to this release.
> 
> This beta contains the worst language misfeature of all time. It's silently snuck in under the guise of a bugfix.

It is a bugfix. It's also a breaking change, for code that relied on the buggy behavior. There may be ways to ease the migration. But it's not a 'misfeature'.

The language changes with /every/ frontend release, often silently or with just a note in some bugzilla entry.. This case isn't any worse and at least this change is actually a real fix.

The scoped import change, which makes local imports effectively 'public' is a much more serious problem. Undoing that one would be painful in the future, if it were to stay. ( http://d.puremagic.com/issues/show_bug.cgi?id=10128 )


> struct S
> {
>     const int x = 7;
>     int y;
> }
> 
> In previous releases, S.x was always 7.
> But now, if you write
> 
> S s = S(5);
> 
> then x gets changed to 5.
> This means that the const variable x has been initialized TWICE!
> 
> This new behaviour is counter-intuitive and introduces a horrible inconsistency.

Yes, this is wrong and just shouldn't be allowed. And, yes, even inside ctors.

> This is totally different to what happens with module constructors (you get a compile error if you try to set a const global if it already has an initializer). Likewise, everywhere else in the language, when you see a const variable with an initializer, the initializer gives its value.

Yes, introducing a "const and initialized, but still mutable" class makes no sense.

> I think the only possible solution is to make it an error to provide a const or immutable member with an initializer.

Except for the issue mentioned above, the new behavior is right. Adding a
keyword ("static") to such declarations should not be a real problem.
AIUI the compiler can be made to list all the places which need changing.
But, yes, the fact that the old (buggy) code compiles, but now silently
drops that implicit "static" isn't ideal.
Would making 'struct S{const a=1;}" illegal for a release really be a
significant improvement? Any code not updated during that 'migration'
period would then still be in the same situation...

> If you are providing an initializer, you surely meant to make it 'static const', and that is certainly true of all existing usages of it.
> As far as I can tell, this new feature exists only to create bugs. No use cases for it have been given. I cannot imagine a case where using this feature would not be a bug.

struct Packet(uint TYPE) {
   immutable uint type = TYPE;
   // ...
}

artur