[comp.lang.c++] References considered crippled

kearns@read.columbia.edu (Steve Kearns) (06/14/89)

I suspect this has already been discussed.  If so, could someone
summarize?

I think that one should be able to assign to references.
Here are some arguments for this idea.  What were the 
decisions for making them unassignable?

(arg 1: for)  If references are just like pointers that
are automatically dereferenced, then to provide the full
functionality of a pointer it should be reassignable.  

(arg 2: against)  There is no syntax available for assigning
to a reference.  If "int bill, frank; int& joe = bill", then "joe = 8"
assigns 8 to bill, but does not change joe.  
(rebuttal)  How about &joe = &frank?  This makes sense, in that it says
that the address of joe should be thought of as the address of frank;
further it should be detectable by the compiler as an address of a reference
on the lhs of an asssignment.  

(arg 3: for)  The current functionality is upwardly compatible of this
change.  Right now a reference is constant.  

(arg 4: against)  Knowing that something is an unchanging reference 
provides the compiler with useful optimizing possibilities.  
(rebuttal)  The const keyword should be able to express a constant
reference to something.  As things stand now, I am forced to allocate extra
references everytime I want to change one, which is inefficient in itself.

(arg 5: against)  References aren't needed at all since they are just a 
shorthand for a constantly dereferenced pointer.  
(rebuttal)  c++ is just a shorthand for assembly language.  but a useful one.

-steve

ark@alice.UUCP (Andrew Koenig) (06/14/89)

In article <6361@columbia.edu>, kearns@read.columbia.edu (Steve Kearns) writes:

> I think that one should be able to assign to references.
> Here are some arguments for this idea.  What were the 
> decisions for making them unassignable?

So far no one has come up with a syntax for doing it and
evidence that it's useful enough to be worth the effort
of implementing.

For example, the syntax you suggested:

	&a = b;

can't be used because it already has a meaning: apply the
unary `&' operator to a and assign b to the result.  This may
sound nonsensical until you realize that a might be of a class
for which unary operator& is defined and returns an lvalue.
-- 
				--Andrew Koenig
				  ark@europa.att.com

kearns@read.columbia.edu (Steve Kearns) (06/15/89)

In article <9483@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>In article <6361@columbia.edu>, kearns@read.columbia.edu (Steve Kearns) writes:
>
>> I think that one should be able to assign to references.
>> Here are some arguments for this idea.  What were the 
>> decisions for making them unassignable?
>
>So far no one has come up with a syntax for doing it and
>evidence that it's useful enough to be worth the effort
>of implementing.
>
>For example, the syntax you suggested:
>
>	&a = b;
>
>can't be used because it already has a meaning: apply the
>unary `&' operator to a and assign b to the result.  This may
>sound nonsensical until you realize that a might be of a class
>for which unary operator& is defined and returns an lvalue.
>-- 
>				--Andrew Koenig
>				  ark@europa.att.com

You have convinced me that "&classref = exp" will not work as a syntax for
resassigning to a reference.  However, in your rebuttal above "a" should
be a REFERENCE to a class for which unary operator& is defined.  The 
basic problem with &classref is that references are dereferenced before
anything else is evaluated, so no ordinary operator can act on a reference.
This is pointed out pretty clearly on pg. 56 of BS' C++ book.

How about using & as a postfix operator?  The postfix operator& would have
higher precedence than dereferencing a reference:

a& = b  // I hope that "& =" is not "&="

Of course, this doesn't address your objection that no evidence exists
for its utility.  All I can offer on that front is the following:

(1) Why use a->b instead of (*c).b?  The reason is that (*c).b is ugly
and hard to type.  If we had reassignable references, a ptr that is
usually dereferenced, like c, could be declared as a reference cref,
so we could write cref.b instead.  The few times we don't want to
derefence could be handled with the cref& notation.

Of course, the most important reason for having references is "var"
parameters in functions, and the ability to return an expression which
can be an lvalue or a value.  Since references in their current form
give us this, it is not the end of the world if references are crippled.
I look at them as notational conveniences.

steele@unc.cs.unc.edu (Oliver Steele) (06/15/89)

kearns@read.UUCP () writes:
>(1) Why use a->b instead of (*c).b?  The reason is that (*c).b is ugly
>and hard to type.  If we had reassignable references, a ptr that is
>usually dereferenced, like c, could be declared as a reference cref,
>so we could write cref.b instead.  The few times we don't want to
>derefence could be handled with the cref& notation.

Do you need reassignable references for this?  It might be simpler to
recognize a.b and a->b as synonymous; in fact, a->b could stand for
(**a).b, (***a).b, ..., as well as for (*a).b, making code that dealt
with Macintosh Handle's, for instance, much easier to read.  There's
never any ambiguity at compile time as to whether something has fields
itself or is a pointer to something that does, and introducing the
synonymity doesn't break existing code.

The disadvantage of such a scheme is that you can't tell the cost of
an expression from looking at it, unless you scan backward for an
declaration.  You might not think to declare a temporary variable to
rewrite a block of code making lots of references to fields of a, but
if the code instead referred to fields of (***a) you might wrap it
in {register foo *pa = **a; ...} and refer to fields of (*pa) instead.
And until optimizing compilers are more common-place, it will be more
important to some people that computationally expensive code look
expensive, than that conceptually simple code look simple.

 ---------------------------------------------------------------------------
 Oliver Steele					  ...!decnet!mcnc!unc!steele
 UNC-CH Linguistics					   steele@cs.unc.edu

dan@oresoft.uu.net (Daniel Elbaum) (06/16/89)

In article <6361@columbia.edu> kearns@read.UUCP () writes:
	.
	.
	.

:(arg 5: against)  References aren't needed at all since they are just a 
:shorthand for a constantly dereferenced pointer.  
:(rebuttal)  c++ is just a shorthand for assembly language.  but a useful one.

(disputation)  On most machines, so is LISP.
Usefulness is a necessary but not sufficient criterion for a
language extension.


-- 
The workaday world must remain transparent to those who maintain it if
they are to find inspired within them a vision of the history they create.

({uunet,tektronix,reed,sun!nosun,osu-cis,psu-cs}!oresoft!(dan)@oresoft.uu.net)