(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