This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: generalized lvalues -- patch outline


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]