From: Matt Austern <austern@apple.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: gcc@gcc.gnu.org, Nathan Sidwell <nathan@codesourcery.com>,
Jason Merrill <jason@redhat.com>
Subject: Re: DR handling for C++
Date: Mon, 20 Sep 2004 21:41:00 -0000 [thread overview]
Message-ID: <461F70B0-0B49-11D9-ADB7-000A95AA5E5E@apple.com> (raw)
In-Reply-To: <414F37E0.3020509@codesourcery.com>
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
next prev parent reply other threads:[~2004-09-20 21:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 20:44 Mark Mitchell
2004-09-20 20:47 ` Dale Johannesen
2004-09-20 20:55 ` Andrew Pinski
2004-09-20 21:26 ` Dale Johannesen
2004-09-20 21:00 ` Mark Mitchell
2004-09-20 21:04 ` Matt Austern
2004-09-20 21:08 ` Mark Mitchell
2004-09-20 21:36 ` Gabriel Dos Reis
2004-09-20 23:42 ` Joseph S. Myers
2004-09-21 8:28 ` Paolo Bonzini
2004-09-21 8:43 ` Paolo Bonzini
2004-09-21 12:39 ` Joseph S. Myers
2004-09-20 20:54 ` Gabriel Dos Reis
2004-09-20 21:01 ` Mark Mitchell
2004-09-20 21:07 ` Gabriel Dos Reis
2004-09-20 21:14 ` Mark Mitchell
2004-09-20 21:41 ` Matt Austern [this message]
2004-09-20 22:32 ` Gabriel Dos Reis
2004-09-20 22:59 ` Mark Mitchell
2004-09-20 23:12 ` Matt Austern
2004-09-20 23:16 ` Mark Mitchell
2004-10-18 9:19 ` Jason Merrill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=461F70B0-0B49-11D9-ADB7-000A95AA5E5E@apple.com \
--to=austern@apple.com \
--cc=gcc@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=mark@codesourcery.com \
--cc=nathan@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).