On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
On 5/19/13 9:11 AM, deadalnix wrote:
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.
That is ridiculous. non nullable would have made the bug non
existent, and even without race condition the problem would
exists. a reference is null, it container shared, then set to
something else. You can put barriers all over the place to make
that sequentially consistent that it wouldn't change anything and
the bug would still arise.
You also never provided any convincing solution to the safety
hole. 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.
I encourage you to look at this :
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
Most new languages removed nullable by default, or limited its
uses (scala for instance, allow for null for limited scope).
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.
Idan Arye > Nil proposal make no sens in a statically typed
language. And you'll find no better kind of null. We have all
tools we need in D to work around null in library.
