From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4431 invoked by alias); 23 Nov 2004 23:00:54 -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 4404 invoked from network); 23 Nov 2004 23:00:49 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sourceware.org with SMTP; 23 Nov 2004 23:00:49 -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 iANN0UQ0020663; Wed, 24 Nov 2004 00:00:30 +0100 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id iANN0Ujh020662; Wed, 24 Nov 2004 00:00:30 +0100 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: "Joseph S. Myers" Cc: Ziemowit Laski , gcc mailing list Subject: Re: generalized lvalues -- patch outline References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <20041117212847.A26376@synopsys.com> <6F5FC748-7BBD-44B9-8DDC-246949F16102@apple.com> <20041118102741.A8347@synopsys.com> <77E8D36A-C0C2-4B03-964C-BEE0FE7BBBC3@apple.com> <98C86CD4-39E2-11D9-B2D5-000A95BCF344@apple.com> <20041119170011.A30410@synopsys.com> <9E6AD708-3A93-11D9-9070-000D9330C50E@apple.com> <20041119174042.A1311@synopsys.com> <90DC5074-3A96-11D9-9070-000D9330C50E@apple.com> <9CD04F70-3CC6-11D9-B847-000D9330C50E@apple.com> <41A253A2.1050205@codesourcery.com> <24BB97A2-3CD3-11D9-B847-000D9330C50E@apple.com> <41A30346.8050602@codesourcery.com> From: Gabriel Dos Reis In-Reply-To: Organization: Integrable Solutions Date: Tue, 23 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/msg00861.txt.bz2 "Joseph S. Myers" writes: | Write down the textual amendments to C99+TC1+TC2 and C++03 which would | introduce your feature. Examine *every* reference to "lvalue" in either | of those standards and explain how your changes interact with that | reference. That's a *minimum* of analysis that would be needed for this. I reiterate my opposing to this cast-as-lvalue abomination. At any rate, he should explain why and how that abomination is different from or equal to the semantics of reinterpret_cast<>. Furthermore, he should articulate clearly how that abomination interacts with the semantics of "old-style" casts -- which are defined in C++ in terms of the "new-style" casts. | People don't need to have read the standards to be aware that casts aren't | lvalues; for example, having read K&R would suffice. I don't think we | should accept random junk just because someone who hasn't familiarised | themselves with the language might throw it at the compiler: we should | inform them of the problem with their code and thereby help them to learn | the languages better. 100% agreed. -- Gaby