From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25522 invoked by alias); 20 Sep 2004 21:36:50 -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 25508 invoked from network); 20 Sep 2004 21:36:48 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 20 Sep 2004 21:36:48 -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 i8KLdodt016729 for ; Mon, 20 Sep 2004 14:39:50 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Mon, 20 Sep 2004 14:36:48 -0700 Received: from [17.201.24.249] (isolde.apple.com [17.201.24.249]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i8KLakRu028417; Mon, 20 Sep 2004 14:36:46 -0700 (PDT) In-Reply-To: <414F4AEC.3080709@codesourcery.com> References: <414F37E0.3020509@codesourcery.com> <461F70B0-0B49-11D9-ADB7-000A95AA5E5E@apple.com> <414F4AEC.3080709@codesourcery.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C6F521B-0B4D-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 23:12:00 -0000 To: Mark Mitchell X-SW-Source: 2004-09/txt/msg01201.txt.bz2 On Sep 20, 2004, at 2:26 PM, Mark Mitchell wrote: > Matt Austern wrote: > >> 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. > > ... > >> 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. > > Aren't we basically in agreement? I think we both agree that we > needn't bother with C++98 separate from C++03. I said above that new > features should require a flag, which I think is what you want too. > If there's a disagreement, it's probably around exactly which > non-feature modifications we should incorporate by default. (For > example, should the enum thing you mentioned be incorporated by > default in our C++03 mode?) I think I'd take those on a case-by-case > basis, incorporating those that looked like they were really fixing > silly things in C++03, and deferring those that are not. We are in agreement, yes. I misread you; I thought you were suggesting that our default mode should conform to "C++03 + all issues in WP status", and I was arguing that it should conform to "C++03 + a few issues in WP that we've selected on a case-by-case basis because we believe they are clear bug fixes." > In this particular case, I'd think we should accept it with a warning > in C++03 mode. (I think the intent of C++03 was to make that case > invalid, but the standard failed to actually say that. ) In this particular case there is no issue in WP status that changes what the C++03 standard says. The only fully resolved issue on this subject is CWG 132, which reaffirms the strict reading of the C++98 standard. I expect that CWG issue 389 will be voted to WP status at the Redmond meeting. If that's correct, then in early 2005 we will have a clear example where the committee will have made one deliberate choice for C++03 and a different choice for C++0x. That's a good example of a place where we'll want our compiler's behavior to depend on a flag that selects which standard we're conforming to. --Matt