From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31386 invoked by alias); 20 Sep 2004 21:08:55 -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 31327 invoked from network); 20 Sep 2004 21:08:54 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 20 Sep 2004 21:08:54 -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 i8KLBtRc001372 for ; Mon, 20 Sep 2004 14:11:55 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Mon, 20 Sep 2004 14:08:53 -0700 Received: from [17.201.24.249] (isolde.apple.com [17.201.24.249]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id i8KL8pg2005710; Mon, 20 Sep 2004 14:08:52 -0700 (PDT) In-Reply-To: <414F37E0.3020509@codesourcery.com> References: <414F37E0.3020509@codesourcery.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <461F70B0-0B49-11D9-ADB7-000A95AA5E5E@apple.com> Content-Transfer-Encoding: 7bit Cc: gcc@gcc.gnu.org, Nathan Sidwell , Jason Merrill From: Matt Austern Subject: Re: DR handling for C++ Date: Mon, 20 Sep 2004 21:41:00 -0000 To: Mark Mitchell X-SW-Source: 2004-09/txt/msg01198.txt.bz2 On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote: > I've been asked to provide my input on the handling of DRs in the C++ > front end. > > Unfortunately, I don't have the messages from the original thread, so > I'm off starting a new thread. > > I certainly agree with Matt and Nathan that there's no point in > supporting C++98 separately from C++03. I also agree that new > features in future revisions of C++ should be supported only under a > flag. I think that fixes for existing features, however, should be > incorporated into the C++03 mode, even if they don't show up in C++03 > itself. (A "defect repot", after all, is supposed to refer to a bug > in the standard.) I think the threshold for incorporating such fixes > should be that the fixes are in WP status, in general, although I'd > consider other fixes if it seems clear that the commitee is going to > accept the change and the change seems important. I'd be unhappy about taking all "WP" changes unconditionally, either CWG or LWG. The fact is that the C++ committee uses DRs in several different ways. In some cases it's "the standard calls for something that's unimplementable or inconsistent, so here's a bug fix", and in other cases it's "we think the standard called for something that's not a good idea, so here's a better redesign." Arguably the committee shouldn't ever be doing the latter, but it does. That's especially true now that the committee is targeting changes at the C++0x working paper rather than at a C++98 technical corrigendum. In the committee's defense: we all know that the line between a bug fix and a feature redesign can sometimes be fuzzy. The committee feels, in my opinion justifiably, that it has more liberty to make changes now that it's working on a new version of the standard. It's using the issues list as one mechanism to track changes for that new version of the standard. My concern is that if we implement all issues in "WP" status we'll be back in the bad place we were in the late 90s: tracking an unstable document, and claiming to implement a "standard" that hasn't actually been standardized. There are some committee issues that ought to be implemented, because there are some cases where the standard really is unimplementable, vague, meaningless, or contradictory. But at this point there is only only official C++ standard, and where that standard is clear and consistent our users have a right to expect that we'll follow it. --Matt