From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6082 invoked by alias); 18 Nov 2004 04:01:16 -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 6044 invoked from network); 18 Nov 2004 04:01:10 -0000 Received: from unknown (HELO smtp3.fuse.net) (216.68.8.176) by sourceware.org with SMTP; 18 Nov 2004 04:01:10 -0000 Received: from gx6.fuse.net ([66.42.134.103]) by smtp3.fuse.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041118040021.YMQC14294.smtp3.fuse.net@gx6.fuse.net> for ; Wed, 17 Nov 2004 23:00:21 -0500 Received: from dellpi.pinski.fam ([66.42.134.103]) by gx6.fuse.net (InterMail vG.1.00.00.00 201-2136-104-20040331) with ESMTP id <20041118040011.FRTO3360.gx6.fuse.net@dellpi.pinski.fam>; Wed, 17 Nov 2004 23:00:11 -0500 Received: from [10.0.0.80] (zhivago.i.pinski.fam [10.0.0.80]) by dellpi.pinski.fam (8.12.2/8.12.1) with ESMTP id iAI415VT031224; Wed, 17 Nov 2004 23:01:06 -0500 (EST) In-Reply-To: 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: <78169FF3-3916-11D9-AEB4-000A95D692F4@physics.uc.edu> Content-Transfer-Encoding: 7bit Cc: Matt Austern , gcc mailing list From: Andrew Pinski Subject: Re: generalized lvalues Date: Thu, 18 Nov 2004 04:21:00 -0000 To: Andrew Pinski X-SW-Source: 2004-11/txt/msg00610.txt.bz2 On Nov 17, 2004, at 10:50 PM, Andrew Pinski wrote: > > On Nov 17, 2004, at 10:47 PM, Matt Austern wrote: > >> 1. It broke valid C++ programs. If we overload a function on >> constness, like foo(int&) and foo(const int&), then invoking it as >> foo((int) x) is required to call the const version. Generalized >> lvalues made us choose the latter. > > If it broke it please file a bug and don't complain that we broke it. Woops I read it wrong but note the C++ front-end removed this extension in 3.4.0 and not just for 4.0.0. Also removing deprecated stuff after a year is more enough time for people to change their code. Also the proposal to deprecate this in C++ was back in May of 2003 which is more than enough time to object to the original proposal. In fact you commented on the original proposal: http://gcc.gnu.org/ml/gcc/2003-05/msg00933.html And you concluded the same thing to remove it: ---- quote -------- I agree, for what it's worth, that this extension should go. It was poorly thought out, and we never specified how it was supposed to interact with other language features. (We've seen two different problems with it in the Apple code base.) Doing language extension correctly takes a lot of work. ----- end quote ------ -- Pinski