Le 17/09/2012 13:07, Jonathan M Davis a écrit :
On Monday, September 17, 2012 13:00:15 deadalnix wrote:
Don't take this wrong, I do know that this is a major breakage, and
would arm the language if applied in any short term manner. Still,
acknowledging error that have been made is usefull.
Not everyone agrees that an error _was_ made. There's a big difference between
acknoweldging that non-nullable references could be useful and agreeing that
having nullable references be the default was a bad idea. I very much that it
will _ever_ happen that non-nullable references would be the default
(certainly, it will _not_ happen in D2), even if they were added.
- Jonathan M Davis
Having written a lot of Java code and reviewed even more, I can assure
you that code written correctly in regard of null is the exception
rather than the rule.
Plus, all null checks tends to add a runtime cost, and most reference
will never be null anyway (expect in case of an attack, an invalid use
of an API, unexpected situation, etc . . .).
The cases where you really want null to be a valid value are the
exception rather than the rule. And most of the code is written like if
references couldn't be null.
I saw many Java software explode because of NullPointerException, and it
was sometime really hard to debug (when race condition get into play for
instance, as I did in Apache Cayenne).
D have already made a step in a direction similar to non nullable
references with other types initialization. float initialize to NaN and
char to invalid codepoints. In other terms poison values. It is useful,
because it avoid to implement the control flow required to ensure that a
variable is initialized, but not what you are advocating here (you don't
seem to consider null as a poison value).
To implement non nullable, whatever the way, such control flow must be
implemented. And it put the question of default initializer back on the
table as it open for more advanced way of handling the problem.
