dmd 2.063 beta 5

[Artur Skawina]

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