null and type safety

[Walter Bright]

Brendan Miller wrote:
> Well.. I can't speak for null pointers in D, but they can definitely
> cause memory corruption in C++. Not all OS's have memory protection.
> *remembers the good old days of Mac OS system 7*

Those machines are obsolete, for excellent reasons <g>. If, for some 
reason, a D implementation needs to be implemented for such a machine, 
the solution is to optionally insert a runtime check analogously to 
array bounds checking.

> Concretely null is a pointer to address zero. For some type T, there
> is never any T at address zero. Therefor a statically typed language
> will prevent you from assigning a poitner to an object that is not of
> type T to a pointer decleared to be type T. That's *the entire point*
> of static typing. T* means "that which I point to is in the set of
> T". T sans the star means "I am in the set of T". Not sometimes. Not
> maybe. Always.

I understand your point, and it sounds right technically. But 
practically, I'm not convinced.

For example, consider a linked list. How do you know you've reached the 
end of the list? By the pointer being null or pointing to some 
"impossible" object. If you pick the latter, what really have you gained 
over a null pointer?