generalized lvalues -- patch outline

[Matt Austern]

On Nov 29, 2004, at 9:59 AM, Joe Buck wrote:

> On Thu, Nov 25, 2004 at 01:06:42PM -0800, Matt Austern wrote:
> [ cast-as-lvalue extension ]
>> I changed my mind, and reluctantly agreed that immediate removal was
>> the best option, because of what Joe Buck pointed out: that this 
>> wasn't
>> a pure extension, but that it actually changed the meaning of legal 
>> C++
>> programs by causing them to select the wrong overload in some cases.
>> This was a serious bug. Seen in that light, removal seemed like the
>> only possible answer: obviously we have to fix bugs.
>
> There is another possible answer if it is decided that some limited 
> form
> of cast-as-lvalue must be kept (presumably under the control of some
> option, or maybe just for Objective-C++): casts can be considered to be
> non-lvalues for the purpose of overload resolution, unless there is no
> match (at which point it can be considered an lvalue so that the
> appropriate operator= or operator++ can be looked up).  This would turn
> the extension back into a pure extension, at the cost of kludging up 
> the
> front end.

That's the sort of thing that I'd recommend, at least for 4.0.  I think 
there
are probably other things we can do for ObjC; my main concern here is
removing a feature without giving users adequate notice.  Lots of users
will end up going directly from a compiler where this feature is fully
documented and supported to one where it's gone, without passing
through the usual intermediate stages of deprecation.

			--Matt