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

[Idan Arye]

On Sunday, 19 May 2013 at 18:22:16 UTC, deadalnix wrote:
> On Sunday, 19 May 2013 at 18:05:03 UTC, Idan Arye wrote:
>> 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.
>>
>
> If you can't initialize the value, you got to assume when you 
> use it that it may not have been initialized and handle that 
> case. You need either an Option (where you have to be explicit 
> about what you do when the thing is null) or a Maybe (where 
> null is ignored and Maybe "contaminate" every result depending 
> on a maybe value).

I don't see how Option and Maybe would have helped your bug. The 
problem was that somewhere in the code the reference was 
perceived as null while in fact it wasn't - so now it will be 
perceived as `None`, and you will have the same problem.

>> 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.
>>
>
> But that is the whole point ! The damn thing should have been 
> initialized in the first place to avoid the bug. And this 
> should have been caught at compile time with any sane type 
> system.
>
> And this is the exact problem with nullable by default : plenty 
> of stuff ends up be null is some weird situation that almost 
> never occurs when they are assumed not to be and the program 
> crashes. NullPointerException now return 4 millions result on 
> google, which is probably around once per java developers.

This is not a problem with "nullable by default" - it is a 
problem with implicit default values. null(or Nil, or None) are 
the only sane default values for reference types - I think you 
would agree that having to construct a new blank object as 
default value for every reference variable would be far worse 
than null...

>> 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.
>
> This solution is complex, do not make any sense in a strongly 
> typed language and don't even solve the presented case.

It does not solve the bug - it is something you HAVE to do given 
the assumptions. If the reference is not nullable, and you can't 
set it to it's real value until later in the code, then you have 
to initialize it to some temporary value.