(non)nullable types

Daniel Keep daniel.keep.lists at gmail.com
Sun Feb 15 18:26:29 PST 2009


Sorry, Jarrett.  You're right; it was uncalled for.  I was having a bad
day, and that was just the straw that broke the camel's back.  My
comments were slightly ambiguous, but I was still upset that trying to
comment on a particular syntax or subfeature of non-nullable types
results in me being chucked bodily into the "hates non-nullable types"
camp.  Again.  :P

To clarify: I am, and always have been, in full support of non-nullable
types, preferably by default.  What I object to specifically in this
case is the requirement to always check that a nullable value is not
null every time it is used.

We have hardware null-dereference exceptions for this.

Another issue is that this subthread is talking about increasingly more
complicated analysis by the compiler to try and determine if a given
nullable value has been checked yet or not.  I don't think this is the
job of the compiler; if I have a nullable value, it's because I wanted a
nullable value, and I should be ready to deal with it appropriately.

Finally, this also creates a distinction between nullable types and
everything else in the type system.  For example, the following test
isn't enforced by the compiler.

int a,b;
// set a and b
if( b != 0 ) int c = a / b;

Maybe it should be, but unless the compiler is -very- smart about it AND
it applies to all types that have potentially "unsafe" values for a
given operation, I don't want to see nullable types singled out.

  -- Daniel



More information about the Digitalmars-d mailing list