dmd 2.063 beta 5

[Steven Schveighoffer]

On Thu, 23 May 2013 05:05:01 -0400, Don <turnyourkidsintocash at nospam.com>  
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.
>
>
> 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.

I disagree.

struct S
{
      const int x;
}

S s1; // x is 0
S s2 = S(5); // x is 5

Adding an initializer simply changes the default value from 0 to whatever  
you want.  It's quite consistent IMO.

The issue you are having is that the old behavior that you rely on is  
inconsistent.  I agree that this is a large problem, especially if you  
have code like you wrote, which likely expects to set y and not x!

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

Module constructors are totally inconsistent with struct/class  
constructors, and have been for some time.  One doesn't "call" a module  
constructor, it's implicitly called.  The semantics are totally  
different.  It also makes no sense to set a value to something different,  
because there isn't more than one instance of the module.  It will be set  
to one value and that's it.

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

This would be my recommendation:

1. Make the above an error.  It is not good to allow code with changed  
semantics to silently compile without intervention.
2. Disable the error with a switch (to allow for the new behavior).
3. In a future release, remove the error.

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

I can see uses.  If you don't want x.init to be the default for x, then  
you need to set it to something else.

For example:

struct Widget
{
    immutable string name = "(unset)"; // instead of ""
}

-Steve