From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17702 invoked by alias); 25 Nov 2004 21:07:08 -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 17145 invoked from network); 25 Nov 2004 21:07:03 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 25 Nov 2004 21:07:03 -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 iAPLE2ii008319 for ; Thu, 25 Nov 2004 13:14:02 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Thu, 25 Nov 2004 13:07:51 -0800 Received: from [17.219.198.232] ([17.219.198.232]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id iAPL6iw6007630; Thu, 25 Nov 2004 13:06:45 -0800 (PST) In-Reply-To: References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <200411232305.56192.ebotcazou@libertysurf.fr> <200411240051.19500.ebotcazou@libertysurf.fr> 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 , "Joseph S. Myers" From: Matt Austern Subject: Re: generalized lvalues -- patch outline Date: Thu, 25 Nov 2004 21:54:00 -0000 To: Gabriel Dos Reis X-SW-Source: 2004-11/txt/msg00999.txt.bz2 On Nov 25, 2004, at 12:30 PM, Gabriel Dos Reis wrote: > Ian Lance Taylor writes: > > | completely breaks. I certainly agree that the warning should have > | been in 3.3.0, > > well, the time travelling machine is a bit expensive for me :-) :-) But it is still a serious concern. I've gone back and forth on this question several times. I think, and have always thought, that this is a bad extension (at least for C++) and that it was put in without enough thought. There are other GNU extensions for which I'd say that too. But that can't be the end of the discussion. The question is how we should remove an extension once we've decided that it's bad. One extreme answer: you can't ever do it, because we must never break user code. Another extreme answer: you should just remove it and not worry about the consequences, and anyone who was using a nonstandard extension deserves whatever they get. I prefer something in the middle. When we first started talking about this, a year ago, I assumed that we would have to phase out this extension over the course of three major releases. I assumed we would start the removal process in 3.5, and the feature wouldn't be completely dead until 3.7. Instead we're going from having the feature fully supported in 3.4.0 to having it completely gone in 4.0. I'm concerned that we haven't given users adequate notice. (Yes, I know we deprecated it in later releases in the 3.3.x and 3.4.x series. But users can be forgiven for only looking at major releases.) 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. So we knew all of that a year ago. I think we know two more things now. 1. Other compilers implement this extension too. I didn't know that. 2. It's possible to tame this extension, to permit assignment-to-cast while still not treating casts as lvalue for the purpose of overload resolution. What #1 suggests to me is that immediate removal was more unfriendly than we'd thought, and what #2 suggests is that immediate removal wasn't the only option. We can fix the overload resolution bug, keep the feature for the cases where people are likely to have used it, deprecate it in 4.0, and remove it in a later major release. --Matt