Re: generalized lvalues

[Ziemowit Laski <zlaski at apple dot com>]

Just to give a little background: the reason for Matt's (and Apple's) 
renewed interest in being able to cast lvalues (so that they retain 
their lvalueness) is that we realized (somewhat belatedly, I admit) 
that removing this feature may cause problems for us.  The first 
problem is one of legacy code with lvalue casts, which I'm sure all of 
us share to some degree regardless of target platform.

The second problem has to do with emerging garbage collection (GC) 
support in ObjC/ObjC++ (which, of course, we hope to offer back to the 
FSF once the design gets baked in, though it is not ready for prime 
time just yet).  It turns out that lvalue casts are extremely useful in 
this context, e.g.:

    void *objPtr;
      :
    (__strong id)objPtr = someOtherObj;

Since objPtr is a plain-vanilla 'void *', it is not in general subject 
to the new NeXT runtime GC regime.  However, if we happen to assign a 
pointer to an ObjC instance to it, then we do want to give a hint to 
the compiler that objPtr _should_ be tracked by GC.  The most 
straighforward -- and intuitive -- way of doing this is precisely via a 
cast applied to the lvalue, as seen above (with '__strong' expanding to 
an appropriate attribute).  While we have investigated some syntactic 
alternatives to the cast in light of the impending lvalue cast removal, 
all of them are counterintuitive in that they fail to express what is 
being done -- namely, altering the type of a variable for a particular 
assignment.  (The GC-enabled compiler will look at the type of the lhs 
to decide whether to emit a write-barrier call.)

So, at least as far as Apple is concerned, it would be great if the 
casts-as-lvalues functionality were retained in GCC. :-)  Of course, if 
the compiler is run in -strict/-pedantic/-ansi/whatever mode, it should 
be free to reject this construct if it is not in the appropriate 
standard.  It's just that there are C/C++ usage idioms out there (as 
non-standard as they may be) for which the lvalue cast is a better 
semantic fit than any alternative.

I'll attempt to address the various technical reasons for removing 
lvalue casts in a separate e-mail.  For the time being, though, I just 
wanted to express a partisan viewpoint on the issue. :-)

Thanks,

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477