generalized lvalues -- patch outline

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

[...]

| 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.

#1 is a circularity.

#2 makes me even more concerned.  Because, for overload resolution
purposes, we usually select overloads based on type of the
arguments.  We do not do overload resolution based on inner syntactic
structures of the arguments -- there are very few exceptions like when
we encounter a null pointer constant in form of an integer constant
with value 0 (but until recently we even failed there). Keeping that
stuff in and trying to squeeze the overload resolution process code
means that we're creating more opportunities to shoot ourselves in the
legs, much louder.  

For C++, it was given data that while Sun compiler accepts a limited
form in C, it rejects it in C++.  If C people are happy with that
stuff, it is OK with me.  But, for C++, it just needs to go.

-- Gaby