Jarrett Billingsley wrote:
On Sat, Sep 26, 2009 at 7:21 PM, Jeremie Pelletier <[email protected]> wrote:
That's exactly the point with nonnull references, they turn access
violations or segfaults into undefined behavior, or worse into generic
behavior that's much harder to track to its source.
I think nonnull references are a nice concept for languages that have a
higher level than D. If I expect references to never be null I just don't
check for null before using them, and let the code crash which gives me a
nice crash window with a backtrace in my runtime.
You're missing the point. You wouldn't have "undefined behavior at
runtime" with nonnull references because there would be NO POINT in
having nonnull references without ALSO having nullable references.
Could your reference be null? Use a nullable reference.
Is your reference never supposed to be null? Use a nonnull reference.
End of problem. You do not create "null objects" and store them in a
nonnull reference which you then check at runtime. You use a nullable
reference which the language *forces* you to check before use.
I don't want the language to force me to check nullable references
before using them, that just takes away a lot of optimization cases.
You could just use the casting system to sneak null into a nonnull
reference and bam, undefined behavior. And you could have nullables
which are always nonnull at some point in time within a scope but your
only way out of the compiler errors about using a nullable without first
testing it for nullity is to use excessive casting.
