On 05/19/2013 09:10 PM, Andrei Alexandrescu wrote:
On 5/19/13 1:35 PM, deadalnix wrote:
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.
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.
...
It is easy to buy that the buggy code would have been rejected by a
stronger type system whereas the fixed code would have passed type
checking. Especially given that it manifested itself as a NPE, which
would not even exist.