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
