From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10657 invoked by alias); 29 Nov 2004 18:46:39 -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 10621 invoked from network); 29 Nov 2004 18:46:35 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 29 Nov 2004 18:46:35 -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 iATIrma0002644 for ; Mon, 29 Nov 2004 10:53:48 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Mon, 29 Nov 2004 10:47:29 -0800 Received: from [17.201.24.249] (isolde.apple.com [17.201.24.249]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id iATIkW26005417; Mon, 29 Nov 2004 10:46:33 -0800 (PST) In-Reply-To: <20041129095939.D1687@synopsys.com> References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <200411232305.56192.ebotcazou@libertysurf.fr> <200411240051.19500.ebotcazou@libertysurf.fr> <20041129095939.D1687@synopsys.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@gcc.gnu.org, Ian Lance Taylor , Gabriel Dos Reis , "Joseph S. Myers" From: Matt Austern Subject: Re: generalized lvalues -- patch outline Date: Mon, 29 Nov 2004 18:57:00 -0000 To: Joe Buck X-SW-Source: 2004-11/txt/msg01149.txt.bz2 On Nov 29, 2004, at 9:59 AM, Joe Buck wrote: > On Thu, Nov 25, 2004 at 01:06:42PM -0800, Matt Austern wrote: > [ cast-as-lvalue extension ] >> I changed my mind, and reluctantly agreed that immediate removal was >> the best option, because of what Joe Buck pointed out: that this >> wasn't >> a pure extension, but that it actually changed the meaning of legal >> C++ >> programs by causing them to select the wrong overload in some cases. >> This was a serious bug. Seen in that light, removal seemed like the >> only possible answer: obviously we have to fix bugs. > > There is another possible answer if it is decided that some limited > form > of cast-as-lvalue must be kept (presumably under the control of some > option, or maybe just for Objective-C++): casts can be considered to be > non-lvalues for the purpose of overload resolution, unless there is no > match (at which point it can be considered an lvalue so that the > appropriate operator= or operator++ can be looked up). This would turn > the extension back into a pure extension, at the cost of kludging up > the > front end. That's the sort of thing that I'd recommend, at least for 4.0. I think there are probably other things we can do for ObjC; my main concern here is removing a feature without giving users adequate notice. Lots of users will end up going directly from a compiler where this feature is fully documented and supported to one where it's gone, without passing through the usual intermediate stages of deprecation. --Matt