This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: DR handling for C++

Mark Mitchell <> writes:

| I've been asked to provide my input on the handling of DRs in the C++
| front end.

Historically, we have not been that methodoligical -- in the C++
front-end.  I believe part of the confusion comes from the fact that
library policies were being discussed within the comments on Matt's

| 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

I don't understand this part.  Are you implying that there is no point
for -std=c++98 behaves differently than -std=c++03 (assuming the last
ever existed?)?

| 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.

That makes a great deal of sense.

| 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.

I'm support of -fpermissive disappearing.  I would not cry if
-pedantic suddenly became inexistent (but I guess that is too much for
the moment).  Indeed, most of the pedwarns should just be hard errors,
with an exceptional set being warnings.  If -pedantic disappeared
then, it would be clear that -pedantic-errors should just go away too.

                                                        Gabriel Dos Reis
	 Texas A&M University -- Computer Science Department
	301, Bright Building -- College Station, TX 77843-3112

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]