null and type safety

Brendan Miller catphive at catphive.net
Wed Nov 5 13:40:25 PST 2008


Walter Bright Wrote:

> 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.

You mean D isn't mean to run on embedded hardware? I thought it was a systems programming language? A lot of hardware today has no MMU, which as I understand it means you can't have memory protection.

If you are only targeting x86 after the ability to have memory protection was added to the hardware... then you can make all kinds of assumptions I guess.

> 
> > 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?

The short answer is you use a variant. It handles the the case where you would use null slightly better (because it is dynamically type safe). For a C style language, just having two kind of pointers might be more natural. Like maybe:

safe T* object1; // does not permit null.
unsafe T* object2; // does perfmit null.

and then have a cast between them:
object1 = (safe T*)object2; // This throws some kind of well defined exception if object2 is null.

The long answer is that the best way to learn about type safety is to check out SML or Ocaml. These are a couple of the few truly statically type safe langauge. Languages like those introduced type safety, and ideas like generics and type inference.

ML is to type safety as Smalltalk is to object orientation. You will probably never write a real world program in ML, but learning it is probably the best way to get a good understanding of where things like type safety and templates came from in the first place.

Also the linked list example you give is actually *way easier* in a language like ML that supports variants. The reason for this is that variants can be used in conjunction with a pattern matching syntax, which is kind of like a switch statement on steroids.

As a side note, I find it interesting that C++ templates are actually much more powerful than the ML style generics they emulate. Specifically, templates can do template metaprogramming, whereas I'm pretty sure this is not possible in any ML style languages.



More information about the Digitalmars-d mailing list