From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8564 invoked by alias); 11 Nov 2002 20:59:30 -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 8552 invoked from network); 11 Nov 2002 20:59:29 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 11 Nov 2002 20:59:29 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gABI0tw23896 for ; Mon, 11 Nov 2002 10:00:55 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 11 Nov 2002 10:00:49 -0800 Received: from apple.com ([17.219.195.52]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gABI0lq11826; Mon, 11 Nov 2002 10:00:47 -0800 (PST) Date: Mon, 11 Nov 2002 12:59:00 -0000 Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Mark Mitchell , Zack Weinberg , "gcc-patches@gcc.gnu.org" To: Michael Matz From: Matt Austern In-Reply-To: Message-Id: <77C2989E-F59F-11D6-BC71-000393B2ABA2@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00697.txt.bz2 On Monday, November 11, 2002, at 05:38 AM, Michael Matz wrote: > On Fri, 8 Nov 2002, Matt Austern wrote: > >> I have a lot less experience as a gcc maintainer than he does, but >> I already have enough experience to have felt burned by language >> extensions. There have been an awful lot of cases where users >> report problems with one extension or another, or worse, with some >> combination of them, and I have to go through the steps of wondering: >> what is this extension supposed to do? was this particular corner >> case ever considered? what does the documentation say, and it is >> right? has this extension gone stale? This sort of confusion is a >> burden for users and implementors. >> >> Partly the reason I lean toward conservatism is my experience on >> standards bodies. (I know I'm not the only person on this >> list with such experience.) I've learned that language design is >> hard. I've learned also that adding a major new language feature, >> and specifying it adequately, is always harder than it looks. It's >> rarely good enough to give a short writeup describing the feature: >> what's more common is pervasive changes throughout the specification, >> as you describe, one by one, how this feature interacts with what's >> already there. > > Now all that being said, do you have any concrete issues with this > particular extension than with extensions in general? Being > conservative > just for being conservative is not very usefull IMO. Whereas my opinion is that an attitude toward extensions other than being conservative is very dangerous. These are general comments because they have to be. If you look at a single extension in isolation, it'll always seem like a good idea. The answer will always be: sure, we can get this to work, and it'll be useful to someone or other. The reason to be scared of uncontrolled extension isn't that any one extension is terrible, it's the overall accumulation of one extension after another. (See Bjarne Stroustrup's _The Design and Evolution of C++_ for a more complete discussion.) 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. --Matt