Re: generalized lvalues -- patch outline

[Matt Austern <austern@apple.com>]

On Nov 25, 2004, at 12:30 PM, Gabriel Dos Reis wrote:

> Ian Lance Taylor <ian@wasabisystems.com> writes:
>
> | completely breaks.  I certainly agree that the warning should have
> | been in 3.3.0,
>
> well, the time travelling machine is a bit expensive for me :-) :-)

But it is still a serious concern.

I've gone back and forth on this question several times.  I think, and 
have always thought, that this is a bad extension (at least for C++) 
and that it was put in without enough thought.  There are other GNU 
extensions for which I'd say that too. But that can't be the end of the 
discussion.  The question is how we should remove an extension once 
we've decided that it's bad.  One extreme answer: you can't ever do it, 
because we must never break user code.  Another extreme answer: you 
should just remove it and not worry about the consequences, and anyone 
who was using a nonstandard extension deserves whatever they get.  I 
prefer something in the middle.

When we first started talking about this, a year ago, I assumed that we 
would have to phase out this extension over the course of three major 
releases.  I assumed we would start the removal process in 3.5, and the 
feature wouldn't be completely dead until 3.7.  Instead we're going 
from having the feature fully supported in 3.4.0 to having it 
completely gone in 4.0.  I'm concerned that we haven't given users 
adequate notice.  (Yes, I know we deprecated it in later releases in 
the 3.3.x and 3.4.x series.  But users can be forgiven for only looking 
at major releases.)

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.

So we knew all of that a year ago.  I think we know two more things now.
  1. Other compilers implement this extension too.  I didn't know that.
  2. It's possible to tame this extension, to permit assignment-to-cast 
while still not treating casts as lvalue for the purpose of overload 
resolution.

What #1 suggests to me is that immediate removal was more unfriendly 
than we'd thought, and what #2 suggests is that immediate removal 
wasn't the only option.  We can fix the overload resolution bug, keep 
the feature for the cases where people are likely to have used it, 
deprecate it in 4.0, and remove it in a later major release.

                  --Matt