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

[deadalnix]

On Sunday, 19 May 2013 at 19:10:28 UTC, Andrei Alexandrescu wrote:
> No, your argument is ridiculous. You make a yarn with precious 
> little detail that describes for everything everyone knows a 
> textbook race condition, essentially ask that you are taking by 
> your word that non-null would miraculously solve it, and, to 
> add insult to injury, and when we don't buy it, you put the 
> burden of proof on us. This is quite a trick, my hat is off to 
> you.
>

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.

>> You also never provided any convincing solution to the safety 
>> hole.
>
> What's the safety hole? Objects of large static size?
>

Limiting object size isn't going to cut it. Or must be super 
restrictive (the protection is 4kb on some systems).

>> We
>> can't even add check only on some edges cases as D also have 
>> values
>> types. The only solution we are left with that is really safe 
>> is to null
>> check every dereference or give up on @safe.
>
> How about using NonNull. We won't change the language at this 
> point to make non-nullable references by default. Even you 
> acknowledged that that's not practical. So now you contradict 
> your own affirmation. What exactly do you sustain, and what are 
> you asking for?
>

1/ NonNull do not work.
2/ It isn't because it is too late to solve a problem that it 
magically isn't a problem anymore.

>> Most new languages removed nullable by default, or limited its 
>> uses
>> (scala for instance, allow for null for limited scope).
>
> So what do you realistically think we should do, seeing that 
> we're aiming at stability?
>

Acknowledge it was a mistake and move on. Use the analysis that 
need to be done to track down @disable this issue to warn about 
uninitialized null stuffs.

>> I once again want to get attention on the fact that GC change 
>> everything
>> in regard to reference, and that the C++ situation is a bad 
>> example.
>
> I don't understand this.
>

I C or C++ you are doomed to manage reference as you need to for 
memory management purpose. In garbage collected languages, you 
ends up with way more unmanaged references, because the GC take 
care of them. Doing so you multiply the surface area where null 
bug can strike.