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

[Andrei Alexandrescu]

On 5/19/13 3:36 PM, deadalnix wrote:
> 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.

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.

>> 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).

Well you got to do what you got to do. Field accesses for objects larger 
than 4KB would have to be checked in @safe code.

>>> 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.

You made the argument that although it does work, people will not use it 
because it's not the default. That's not quite "does not work". This 
also ruins your point because if people don't find it worth writing 
NonNull!T instead of T, it means non-null doesn't buy them anything 
worthwhile.

> 2/ It isn't because it is too late to solve a problem that it magically
> isn't a problem anymore.

You are blowing it out of proportion. Null references are hardly even on 
the radar of the bug classes I'm encountering in the style of 
programming of the three groups I worked in at Facebook, and also my 
previous employers. People I meet at conferences and consulting gigs 
never mention null references as a real problem, although I very often 
ask about problems. I find it difficult to agree with you just to be nice.

>>> 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.

I'd give it more thought if we designed D from scratch. I think it's 
safe to move on. At any rate, I'd love if we got NonNull working nicely 
so we accumulate more experience with it.


Andrei