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

[Idan Arye]

On Sunday, 19 May 2013 at 17:46:13 UTC, Simen Kjaeraas wrote:
> On Sun, 19 May 2013 19:12:15 +0200, Idan Arye 
> <GenericNPC at gmail.com> wrote:
>
>> It's a good practice to initialize references(and all other 
>> types of variables) as soon as possible - and if possible, 
>> right away in the declaration. If that reference started as 
>> null, it's safe to assume it was not possible to initialized 
>> it at declaration, so it was intentionally initialized with 
>> null(if there was no initialization Java would scream at you).
>>
>> Now, let's assume that reference was non-nullable. It is safe 
>> to assume that this change would not remove the obstacle that 
>> prevented that reference from being initialized right away in 
>> the declaration - so you still need to initialize it to 
>> something else - let's call that something `Nil`. Nil is an 
>> object that tells you that the reference has not yet been 
>> initialized.
>
> Uhm, no. Nononono. No. This is a complete and utter fallacy. 
> What you
> have just done is define Nullable!(NonNullable!T). I should not 
> have to
> explain too closely why this is a bad thing and should not be 
> done.

These are the assumptions I'm working with:
  - We can't use a nullable reference
  - We can't initialize the reference upon declaration to it's 
real value.

The first assumption is required because we want to describe how 
the bug scenario deadalnix brought up would look like if 
references were non-nullable. The second assumption is required 
because if we could initialize the reference upon declaration to 
it's real value, we should have just done it in the first place 
and avoid the whole race hazard.

Now, I'm not saying the solution I presented is good - I'm trying 
to show that given those two assumptions, we are forced to use 
this bad solution.