(non)nullable types

[Jarrett Billingsley]

On Wed, Feb 11, 2009 at 3:40 PM, Christopher Wright <dhasenan at gmail.com> wrote:
>
> Your language features should get rid of bugs that are easy to make and
> difficult to track down. It's not worthwhile to alter your language to
> remove easily found, easily fixed bugs.

Except when someone passes a null reference into a large, complex data
structure and that reference is passed around blindly and never
dereferenced until somewhere far down the line, giving you a segfault
in a program location that you never would have expected.  By then
it's much more difficult to figure out where that null reference came
from.  I've had a much larger share of these kinds of null reference
errors than the "oops someone passed a null into my function and I
didn't account for it" kind.  Disallowing null references on most
public interface functions from the beginning would make those kinds
of bugs nonexistent.

Otherwise, you have to put explicit runtime null checks on every
public interface function, and woe to the guy who forgets to do that.
Not to mention you now have to write all these stupid unittests to
throw nulls at the code to see if it barfs correctly, rather than it
being a simple error caught by the compiler.  This reeks of the
development problems that dynamic languages have!  We have static
compilation for a reason; why not take advantage of it?

Having null references be the default - nay, the only - option is a
useless bit of C arcana that should be dropped.  It's a dangerous use
of in-band signaling on par with error return codes.