From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29541 invoked by alias); 18 Nov 2004 03:47:24 -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 29526 invoked from network); 18 Nov 2004 03:47:19 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 18 Nov 2004 03:47:19 -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 iAI3roCM019504 for ; Wed, 17 Nov 2004 19:53:50 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Wed, 17 Nov 2004 19:47:56 -0800 Received: from [17.219.197.172] ([17.219.197.172]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id iAI3lHCf015945 for ; Wed, 17 Nov 2004 19:47:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: gcc mailing list From: Matt Austern Subject: generalized lvalues Date: Thu, 18 Nov 2004 03:50:00 -0000 X-SW-Source: 2004-11/txt/msg00606.txt.bz2 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