dmd 2.063 beta 5

[Don]

On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
> 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.

No. Disallowing the problematic initializer fixes the bug. 
Allowing it, but with a different meaning, is a new feature.


> 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.

No, it's not, it's a fix plus a new misfeature.

> 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...

No, it should be illegal for ever. It's not sensible behaviour.

>
>> 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;
>    // ...
> }

But that allows you to write:

auto w  = Packet!(7)(6);

which sets type to 6 !
That makes no sense. It's a bug. Probably you meant:

struct Packet(uint TYPE) {
     static immutable uint type = TYPE;
     // ...
}
which doesn't store a copy of the '7' in every instance.