From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21062 invoked by alias); 12 Nov 2002 16:20:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 21034 invoked from network); 12 Nov 2002 16:20:22 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 12 Nov 2002 16:20:22 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id gACGHWp01896; Tue, 12 Nov 2002 08:17:32 -0800 Date: Tue, 12 Nov 2002 08:20:00 -0000 From: Mark Mitchell To: Michael Matz , Matt Austern cc: Zack Weinberg , "gcc-patches@gcc.gnu.org" Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests Message-ID: <33000000.1037117851@warlock.codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-11/txt/msg00733.txt.bz2 >> So for me, the question isn't whether an extension might be useful >> for someone, but whether it's so very useful to enough people that it >> can overcome a strong bias against adding extensions. Some extensions >> pass that test; I'm not yet convinced that this one does. > > Yes, and I ask for specific reasons why this wouldn't pass. I (and probably Matt) are going to argue that the burden is not on us to provide a specific reason *not to* have an extension; the burden is on you *to* provide a specific reason to have the extension. The reason that I would find compelling is that there is no way to achieve some vital piece of functionality without the extension. Richard's recent TLS extension met that criteria to me; that gives you a portable way of writing code that takes advantage of the TLS support in the linker. I couldn't think of any other good way to do that, so I didn't object. Introducing a new control-flow construct into a language that has been used for decades without that control-flow construct is a much more radical change. There's no question the extension would be useful; the question is whether it is essential. Anyhow, I think you're beating a dead horse. :-) Richard has agreed to try to implement and use longjmp_unwind. There's no question that function would be useful to people in other situations, and it doesn't require any language extension. If Richard's attempt fails for some reason, we can reconsider. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com