From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13713 invoked by alias); 25 Nov 2004 23:13:31 -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 13503 invoked from network); 25 Nov 2004 23:13:20 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sourceware.org with SMTP; 25 Nov 2004 23:13:20 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id iAPNCqQ0001062; Fri, 26 Nov 2004 00:12:52 +0100 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id iAPNCqnf001061; Fri, 26 Nov 2004 00:12:52 +0100 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Matt Austern Cc: gcc@gcc.gnu.org, Ian Lance Taylor , "Joseph S. Myers" Subject: Re: generalized lvalues -- patch outline References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <200411232305.56192.ebotcazou@libertysurf.fr> <200411240051.19500.ebotcazou@libertysurf.fr> From: Gabriel Dos Reis In-Reply-To: Organization: Integrable Solutions Date: Thu, 25 Nov 2004 23:27:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg01003.txt.bz2 Matt Austern writes: [...] | 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. #1 is a circularity. #2 makes me even more concerned. Because, for overload resolution purposes, we usually select overloads based on type of the arguments. We do not do overload resolution based on inner syntactic structures of the arguments -- there are very few exceptions like when we encounter a null pointer constant in form of an integer constant with value 0 (but until recently we even failed there). Keeping that stuff in and trying to squeeze the overload resolution process code means that we're creating more opportunities to shoot ourselves in the legs, much louder. For C++, it was given data that while Sun compiler accepts a limited form in C, it rejects it in C++. If C people are happy with that stuff, it is OK with me. But, for C++, it just needs to go. -- Gaby