Re: generalized lvalues

[Joe Buck <Joe.Buck@synopsys.COM>]

On Thu, Nov 18, 2004 at 03:28:15PM -0800, Ziemowit Laski wrote:
> So, at least as far as Apple is concerned, it would be great if the 
> casts-as-lvalues functionality were retained in GCC. :-)  Of course, if 
> the compiler is run in -strict/-pedantic/-ansi/whatever mode, it should 
> be free to reject this construct if it is not in the appropriate 
> standard.  It's just that there are C/C++ usage idioms out there (as 
> non-standard as they may be) for which the lvalue cast is a better 
> semantic fit than any alternative.

The main reason why cast-as-lvalue is bad news for C++ is its effect
on overloading.  Consider:

void func(const Type&);
void func(Type&);

...

	func((Type)expression);

cast-as-lvalue causes the wrong overloaded function to be called.
The user would expect the cast to produce a temporary, meaning that
the const version is called; however, because of the extension, the
non-const version is called.  This is not a small matter; given a
non-const reference we can normally be sure that we have a real object
of the given type, that we can write that object, save its address, etc.
With a non-const reference, it might be bound to a temporary.

Notice that in the above example, the programmer had no idea that his
or her code was affected by an extension.  There are two versions of
func and the compiler chooses the wrong one.  We shouldn't require
-ansi or -pedantic to make correct code work correctly; in the past,
we just use them to reject more incorrect code.

If you must retain this extension, then at minimum we would need to
prevent cast-as-lvalue from modifying the type of the cast expression
for the purposes of overloading; even though it's an lvalue for the
purpose of assignment, it can't be treated as an lvalue for purposes
of operator overloading.  That might be tricky.


 
> I'll attempt to address the various technical reasons for removing 
> lvalue casts in a separate e-mail.  For the time being, though, I just 
> wanted to express a partisan viewpoint on the issue. :-)
> 
> Thanks,
> 
> --Zem
> --------------------------------------------------------------
> Ziemowit Laski                 1 Infinite Loop, MS 301-2K
> Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
> Apple Computer, Inc.           +1.408.974.6229  Fax .5477