public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Mitchell <mark@codesourcery.com>
To: gcc@gcc.gnu.org
Cc: Matt Austern <matt@lafstern.org>,
	 Nathan Sidwell <nathan@codesourcery.com>,
	Jason Merrill <jason@redhat.com>
Subject: DR handling for C++
Date: Mon, 20 Sep 2004 20:44:00 -0000	[thread overview]
Message-ID: <414F37E0.3020509@codesourcery.com> (raw)

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.

In the particular case of PR 15049, I think we should go with Matt's 
approach.  I'm not sure that, in general, I'd want to leave in support 
for what the commitee basically considers to be bugs in C++03, but in 
this case it looks very easy to do that, so we should probably go ahead.

I think that part of the confusion here comes from the 
-pedwarn/-fpermissive situation.  I think -fpermissive should just be 
removed.  I think that many of our pedwarns should become errors, many 
should become warnings, -pedantic-errors should be off by default.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

             reply	other threads:[~2004-09-20 20:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-20 20:44 Mark Mitchell [this message]
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
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=414F37E0.3020509@codesourcery.com \
    --to=mark@codesourcery.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=matt@lafstern.org \
    --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).