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

[Andrei Alexandrescu]

On 5/19/13 1:12 PM, Idan Arye wrote:
> On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
>> On 5/19/13 9:11 AM, deadalnix wrote:
>>> On Sunday, 19 May 2013 at 13:08:53 UTC, Andrei Alexandrescu wrote:
>>>> Sounds like a race problem unrelated to null. With non-null objects
>>>> the race would have manifested itself in a different way, perhaps even
>>>> more pernicious.
>>>>
>>>
>>> It is both a race condition and a null problem.
>>
>> No, it's just a race condition.
>>
>>> And having non nullable
>>> type would have been a compile time error instead of days of debugging.
>>
>> No, the race condition would have stayed.
>>
>>
>> Andrei
>
> I believe this claim requires an explanation:
>
> 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.
>
> So, in the original bug the reference "could be seen
> as null where it was assumed everywhere to be set.". But now we don't
> have null - so that piece of code that thought the reference is null
> would now think that it is... what? The initialization value? No!
> Because we didn't switch from initializing the reference with null to
> initializing it with the later initialization value - we couldn't do it.
> Instead, we had to use Nil. So now, the reference 'could be seen as Nil
> where it was assumed everywhere to be set'...
>
> Now, if you are lucky and your Nil is the better-kind-of-null that is
> used in dynamic object oriented languages, you'll get a nil exception -
> which is just as good as null exception. But if you are not so lucky,
> and you had to declare Nil as a blank object of the type of that
> reference, you are going to have logical bug, which is far worse than
> exceptions...

So the race would have manifested it just the same, except under the 
name of Nil instead of null.

Andrei