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.
