dmd 2.063 beta 5

[Artur Skawina]

On 05/23/13 15:12, Don wrote:
> 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 !

No, it doesn't - this is why the "const and initialized, but still mutable" class
is a bad idea. Modifying already initialized immutable data needs to be forbidden.

Yes, there are a few situation where it, in theory, can make sense - but given D
semantics (no "implicit" RT evaluation of initializers) I don't think special
casing them here is a good idea. Since even the "old" semantics (w/ the implicit
"static) didn't allow it, it would be better to start out conservatively, and
only allow the safe mutations if they turn out to be absolutely necessary. Which
right no I don't think they are.

> That makes no sense. It's a bug. 

'Packet!(7)(6);' should not compile, as it makes no sense - if I wanted 'Packet.type'
to be mutable, I wouldn't be doing this.

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

No, I really meant to have a type with a constant field at a specific offset.

There is no reason to disallow this. It's just that the previously implicit
'static' makes the migration harder, I know. Also, the old semantics are not
expected by anyone new to the language - it was a source of bugs, often
subtle and misleading.

artur