Re: generalized lvalues -- patch outline

[kaih@khms.westfalen.de (Kai Henningsen)]

gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 23.11.04 in <m38y8to2sz.fsf@uniton.integrable-solutions.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.

That's a somewhat circular history, but I can't see any circular  
reasoning. If the goal is (say) MS compatibility, it doesn't matter if MS  
is the way it is because it wanted to be somewhat gcc compatible, or  
because they independently had the same idea, or whatever. It just matters  
that they are the way they are.

In any case, *if* something like that comes back, I think it should be  
done this way:

1. To get it, you need an explicit flag of some kind - it's not there by  
default, so we have a guarantee that it doesn't hurt programs which don't  
use it. (I have no preferences as to what flag would be appropriate, just  
that it be off by default.)

2. It is defined exactly what it does, preferrably as a syntactic  
transform to a standard (or at least different) language construct (this  
also helps people who want to get rid of it).

For example (and I don't claim this is the semantic it ought to have),

        modification((type)lvalue)

        ->

        ({
                type __tmp = (type)lvalue;
                modification(__tmp);
                lvalue = (typeof(lvalue))__tmp;
                lvalue;
        })

(and similarly for any other allowed general lvalue constructs).

MfG Kai