dmd 2.063 beta 5

[Steven Schveighoffer]

On Thu, 23 May 2013 12:09:26 -0400, Don <turnyourkidsintocash at nospam.com>  
wrote:

> On Thursday, 23 May 2013 at 13:52:49 UTC, Steven Schveighoffer wrote:
>> 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
>
>
> Of course! It's an uninitialized variable! Try making x a float, and  
> you'll get NaN.

No, it's initialized to NaN.  If it was truly uninitialized, then it would  
be garbage, like C.

In other words, *something* writes NaN into that memory location (or 0, or  
whatever).  The initializer simply dictates what to write.

>> S s2 = S(5); // x is 5
>
> ---
>> 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 ""
>> }
>
> That is just an awful workaround for the lack of default constructors.

Why?  The compiler blits a bit-pattern onto the struct before  
initialization.  Why should we not be given the ability to control that  
bit pattern?  It's just data!

I find the argument against this quite puzzling, we should have as much  
power as possible over how the compiler treats our custom types.  I think  
your arguments simply stem from the fact that you did not specify static  
for your static variables, and the compiler loosely accepted that until  
now.

-Steve