Re: To Initialise or not

[bobduff@world.std.com (Robert A Duff)]

In article <Dqq1F9.CK3@thomsoft.com>, Keith Thompson <kst@thomsoft.com> wrote:
>The real problem, I think, is that the access value null plays two
>different roles: as an uninitialized (garbage) value, and as a legitimate
>access value that doesn't designate any object.

Exactly.

>...  If I were designing a
>new language, I'd be tempted to define a second distinguished access
>value called, say, "invalid".  The value null would act like it does
>in Ada: it doesn't point to anything and an attempt to dereference it
>raises Constraint_Error.  The value invalid would be the default initial
>value of all access types; an attempt to dereference it *or to reference
>it* would raise Constraint_Error.

Why restrict it to access values?  As I said in another post, an integer
array index is a pointer, just like an access value, and allowing
totally undefined array index values can do just as much damage as
allowing undefined access values.

While we're talking about language design: I think the idea of always
having a single "special" value, and always calling it "null" is ugly.
Some access types shouldn't *have* a null value at all.  (E.g. consider
a circular linked list, with a dummy header element.  The links can
*never* be null, unless there's a bug.)  And when I *do* need an extra
"special" value, why is it always called "null"?  In one case, it ought
to be called "End_Of_List".  In another case it should be called
"Not_Yet_Determined" or something.  And why can't I have *two* of the
special things?

- Bob