Re: generalized lvalues -- patch outline

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Matt Austern <austern@apple.com> writes:

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

I fear there is a circular reasoning here: compilers tend to be
bug+feature compatible; there are high chances that those mentioned
compiler implement that dubious construct because gcc invented them in
the first place.  Now, saying those compilers implement that questionable
construct as a reason to resurect that abomination does not sound
right to me.

-- Gaby