From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6866 invoked by alias); 18 Nov 2004 23:44:25 -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 6847 invoked from network); 18 Nov 2004 23:44:20 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 18 Nov 2004 23:44:20 -0000 Received: (qmail 8466 invoked from network); 18 Nov 2004 23:44:20 -0000 Received: from localhost (HELO taltos.codesourcery.com) (zack@127.0.0.1) by mail.codesourcery.com with SMTP; 18 Nov 2004 23:44:20 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Thu, 18 Nov 2004 15:44:19 -0800 To: Matt Austern Cc: Ziemowit Laski , gcc mailing list Subject: Re: generalized lvalues References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> <852F83A5-39B9-11D9-8317-00039390FFE2@apple.com> From: Zack Weinberg Date: Thu, 18 Nov 2004 23:49:00 -0000 In-Reply-To: (Matt Austern's message of "Thu, 18 Nov 2004 15:36:40 -0800") Message-ID: <87zn1eiuy4.fsf@codesourcery.com> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00650.txt.bz2 Matt Austern writes: > On Nov 18, 2004, at 3:28 PM, Ziemowit Laski wrote: >> 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. I would like to point out that in *my* arrogant opinion, this use of lvalue casts is completely *un*intuitive; I would prefer either declaring the void * with the "this is a GC root" attribute in the first place, e.g. id object; void *__gcroot ptr; ... ptr = object; or (if for some reason that is impossible) a builtin function call, e.g. id object; void *ptr; ... __builtin_gc_register(ptr); ptr = object; > 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. Not only that, but unless someone brought a *very* compelling argument to the table, we wouldn't even consider it for 4.0 - the time for adding features to 4.0 was six months ago. zw