TITLE: operator ++ and lvalues


SHELEST: artyom@kansmen.com (Art Shelest)

I can see no use for prefix ++ returning an l-value for built-in types (and 
for redefined operators, programer defines how it works).

Does  "++i = 9;" look to you as ridiculous as it looks to me?


KOENIG: ark@research.att.com (Andrew Koenig), 1 Aug 96

Actually, having these operators return lvalues was mostly my idea,
and it still doesn't look ridiculous if you look in the right places.

For example, although the ability to say "++i = 9;" buys you little,
suppose you have a function declared this way

	extern void f(const int&);

and you call f(++i).  Isn't it nice that you can pass a reference
to i directly to f without having to make a copy of it?

Moreover, the real reason that things like ++i return lvalues is as part
of a general rule that built-in operators that return one of their arguments
return lvalues if the arguments are lvalues.  That allows conveniences
like "(x>y? x: y) = 0", which is considerably less pointless than "++i = 9".
It also preserves an important identity.  Consider the following function:

	T& assign(T& x, const T& y)
	{
		x = y;
		return x;
	}

It is tempting to rewrite the two statements in the body as

		return (x = y);

but that works only if = returns an lvalue.  It can be talked into doing so
if T is a user-defined type, but what about if T is a built-in type?
To arrange that, we made the language do it automatically.

SHELEST:

I know that ANSI and B.S. and others spend a great deal of time discussing 
changes to existing draft, and there should be strong very reasons to break 
existing C compatibility. Would someone enlighten me what were these
reasons in this case?

KOENIG:

I would agree with you that it would be a bad idea if there were a
C incompatibility involved, but there isn't.  If this statement sounds
surprising, consider that a C incompatibility exists only in the case
of a legal C program that behaves differently in C++.