Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)

[Steven Schveighoffer]

On Sun, 19 May 2013 16:03:24 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 5/19/13 3:36 PM, deadalnix wrote:
>> I described a very usual null bug : something is set to null, then to a
>> specific value. It is assumed not to be null. In a specific case it is
>> null and everything explode.
>>
>> The concurrent context here made it especially hard to debug, but isn't
>> the cause of the bug.
>>
>> Additionally, if you don't have enough information to understand what
>> I'm saying, you are perfectly allowed to ask for additional details This
>> isn't a shame.
>
> Your argument has been destroyed so no need to ask details about it.  
> Replace "null" with "invalid state" and it's the same race in any  
> system. Let's move on.

I just wanted to chime in with this understanding of the bug that I am  
reading from deadalnix's descriptions:

SomeObj obj;
shareTheObj(&obj); // goes to other threads
obj = new SomeObj; // initialize obj

This is likely simpler than the actual problem, but I think this is the  
gist of it.

A Non-Nullable solution WOULD solve the race:

SomeObj obj; // Compiler: nope, can't do that, must initialize it.

Now, with an "invalid state" not available like null, is the developer  
more likely to go through the trouble of building an invalid state for  
obj, in order to keep the racy behavior?  No.  He's just going to move the  
initialization:

SomeObj obj = new SomeObj;
shareTheObj(&obj);

In essence the point of the anecdote is that a Non-Nullable reference  
would have PROMOTED avoiding the race condition -- it would have been  
harder to keep the racy behavior.

I'm not saying that I think we need NN references as a compiler-supported  
type, or that it needs to be the default, or that NN references ALWAYS  
solve race conditions.  I'm just pointing out what I see is an obvious  
misinterpretation of the underlying story.

-Steve