Re: generalized lvalues -- patch outline

[Matt Austern <austern at apple dot com>]

On Nov 22, 2004, at 12:45 PM, Andrew Pinski wrote:

> On Nov 22, 2004, at 3:39 PM, Ziemowit Laski wrote:
>
> > On 19 Nov 2004, at 17.50, Ziemowit Laski wrote:
> >
> > > To put it another way, I'm only concerned with cases where the 
> > > compiler currently complains
> > > about assigning to a non-lvalue, and the non-lvalue in question is a 
> > > cast of an lvalue.
> >
> > Indeed, I now appear to have a mainline mod for C and C++ which 
> > allows assignment to lvalue casts for pointer types.  What follows is 
> > a high-level synopsis of what I did; if there is interest, I can whip 
> > up a full-fledged patch, complete with docs.  Please let me know.
>
>
> Just use a builtin as proposed by Nathan and others for the problem you
> are trying to solve.  The syntax for casts as lvalue just looks bad.
> The builtin can return a reference (yes even in the C front-end you
> can have references [varargs is an example of which is used as
> references in the front-end]).

Unfortunately, there is another reason for allowing some tamed version 
of assignment to casts: compatibility with other compilers.  Microsoft 
and CodeWarrior both allow this in one form or another.  (Microsoft for 
C only, CodeWarrior for C++ as well.  CodeWarrior only allows some 
limited forms of assignments to casts, and doesn't treat a cast as a 
true lvalue, so they still get overload resolution right.)

If it's possible to make some limited subset of this work without 
hurting C++ correctness, then I think we ought to do it.  We don't want 
to gratuitously break compatibility with other compilers.

			--Matt