From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7555 invoked by alias); 18 Nov 2004 16:23:23 -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 7408 invoked from network); 18 Nov 2004 16:23:13 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 18 Nov 2004 16:23:13 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id iAIGTHM0009946 for ; Thu, 18 Nov 2004 08:29:17 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Thu, 18 Nov 2004 08:23:51 -0800 Received: from [17.201.21.188] (jahan5.apple.com [17.201.21.188]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id iAIGMtvX003316; Thu, 18 Nov 2004 08:22:56 -0800 (PST) In-Reply-To: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <880AA6A7-397D-11D9-A788-000A95BA54A6@apple.com> Content-Transfer-Encoding: 7bit Cc: gcc mailing list From: Fariborz Jahanian Subject: Re: generalized lvalues Date: Thu, 18 Nov 2004 17:14:00 -0000 To: Matt Austern X-SW-Source: 2004-11/txt/msg00624.txt.bz2 What was the rational to have this extension in the first place. Maybe we sould dig this out before declaring that it was a 'bad idea'. - fariborz On Nov 17, 2004, at 7:47 PM, Matt Austern wrote: > Could somebody remind me, please, of the reasons we removed > generalized lvalues? I know there were several reasons, but I'm not > sure if I've ever seen a complete list. Here are the reasons I can > reconstruct from memory: > 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. > 2. It was underspecified. There were cases, again especially in C++ > in the presence of operator overloading, where nobody was quite sure > either what it did or what it was supposed to do. > 3. I have the vague sense that it caused back end bugs, but I can't > find them offhand. > > Anything else? (Incidentally, I think all of these apply to > cast-as-lvalue. I haven't heard of any problems caused by > conditional-as-lvalue or comma-expression-as-lvalue.) > > The reason I'm asking: I think some people are going to find the > removal a nasty surprise. Yes, it was deprecated in 3.3.x and 3.4.x, > but not everyone upgrades to the latest release of older branches. I > imagine some people won't have noticed the discussion about removal > until they upgrade to 4.0 and see that it's gone. At that point we'll > have three choices: convince them that removing it made the compiler > better, or reconsider and put it back, or refuse to put it back, don't > tell anyone why it's gone, and live with unhappy users who think we're > stupid and capricious. If we want to go with one of the first two > options, it'll help to have a collection of reasons. > > --Matt >