Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!odi!benson
From: benson@odi.com (Benson Margulies)
Newsgroups: comp.lang.c++
Subject: Reference Semantics
Message-ID: <315@odi.ODI.COM>
Date: 4 May 89 19:52:16 GMT
Reply-To: benson@odi.com
Organization: Object Design Inc., Burlington, MA
Lines: 83

I've found a use for reference variables that refer via the null
pointer. In the starkest of terms,

       example& t = *(example *)0;

I'd like to clarify the official language philosophy in this area, and
I hope to persuade the designers that this is a good use.

Consider an interface like:

gadget& find_a_gadget (char * gadget_name, int& error);

What should this do if the named gadget cannot be found, and error
signalling out-of-line is undesirable?

It seems natural to me for find_a_gadget to do the following:

	error = ENOGADGET;
	return *(gadget *)0;

Furthermore, the caller of find_a_gadget is welcome to assign the
result of find_a_gadget to reference variable r, and test

	if(&r == (gadget *)0) ...

to detect a failure to get one.

So I would like to see the definition of the language state that it is
permissible to say:

	type& var = *(type *)0;

with the condition that once this is done, the only legitimate action
with var is to take its address and compare it. Along with this, 
the definition would have to state the reasonableness of:

	return *(type 0);

in a function of type type&.

What I would like the definition of the language NOT to state is that
the above declaration is invalid and that an implementation can do
whatever it wants with it. 

One might object to my usage, claiming that I should be returning a
pointer. But it looks ugly to have a protocol defined with some
reference returns and some pointer returns. IMHO, reference returns
(and references) make for much more legible code, so it would be a
shame to have to avoid them to handle errors.

As an additional suggestion, it occurs to me that the following might
be a good extension of the language:

	type& ref = initial_ref;

	&ref = new_reference;

&foo on the LHS has no current semantics, so defining it to mean
rebind the reference conflicts with nothing. This allow somewhat
neater code for a variety of cases. One in particular is the desire to
iterate over an array of objects. Currently, one can write:

	for(int x = 0; x < limit; x ++) {
	    foo& r = array[x];
	    ...
        }

better, IMHO, would be

	for(int x = 0; x < limit; x ++) {
	    &r = array[x];
	    ...
        }

or even:

	for(foo& r = array; &r < &array[limit]; &foo ++) {
	    ...

thank you for your kind attention,

-- 
Benson I. Margulies