From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25206 invoked by alias); 18 Nov 2004 23:28:23 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25193 invoked from network); 18 Nov 2004 23:28:18 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 18 Nov 2004 23:28:18 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iAINYrbQ023459 for ; Thu, 18 Nov 2004 15:34:53 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Thu, 18 Nov 2004 15:28:56 -0800 Received: from [17.219.197.191] ([17.219.197.191]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id iAINSFXj028072; Thu, 18 Nov 2004 15:28:16 -0800 (PST) In-Reply-To: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <852F83A5-39B9-11D9-8317-00039390FFE2@apple.com> Content-Transfer-Encoding: 7bit Cc: Matt Austern From: Ziemowit Laski Subject: Re: generalized lvalues Date: Thu, 18 Nov 2004 23:36:00 -0000 To: gcc mailing list X-SW-Source: 2004-11/txt/msg00645.txt.bz2 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