From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31141 invoked by alias); 18 Nov 2004 23:36:47 -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 31089 invoked from network); 18 Nov 2004 23:36:42 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 18 Nov 2004 23:36:42 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iAINhHn8029283 for ; Thu, 18 Nov 2004 15:43:17 -0800 (PST) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Thu, 18 Nov 2004 15:36:42 -0800 Received: from [17.201.24.249] (isolde.apple.com [17.201.24.249]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id iAINaeJH015925; Thu, 18 Nov 2004 15:36:40 -0800 (PST) In-Reply-To: <852F83A5-39B9-11D9-8317-00039390FFE2@apple.com> References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> <852F83A5-39B9-11D9-8317-00039390FFE2@apple.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: gcc mailing list From: Matt Austern Subject: Re: generalized lvalues Date: Thu, 18 Nov 2004 23:37:00 -0000 To: Ziemowit Laski X-SW-Source: 2004-11/txt/msg00646.txt.bz2 On Nov 18, 2004, at 3:28 PM, Ziemowit Laski wrote: > 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. Just a reminder: the word "impending" isn't quite right. It's not that cast-as-lvalue isn't going away, but that it's already gone. It won't come back unless someone does the work to put it back, including documentation, testing, and integration with the 4.0 back end. Yes, if we discover that removing it caused major problems then we might be forced to consider doing that work. But we'd better be aware that at this point you aren't proposing that we avoid doing something, you're proposing a project to add functionality that isn't here. --Matt