DR handling for C++

DR handling for C++

[Mark Mitchell]

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

Re: DR handling for C++

[Dale Johannesen]

On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:

>   I think -fpermissive should just be removed.

The eon SPECmark will no longer build if we do that.

Re: DR handling for C++

[Andrew Pinski]

On Sep 20, 2004, at 4:34 PM, Dale Johannesen wrote:

>
> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>
>>   I think -fpermissive should just be removed.
>
> The eon SPECmark will no longer build if we do that.

Huh? I had been building eon without -fpermissive for
a long time.


Thanks,
Andrew Pinski

Re: DR handling for C++

[Dale Johannesen]

On Sep 20, 2004, at 1:43 PM, Andrew Pinski wrote:
> On Sep 20, 2004, at 4:34 PM, Dale Johannesen wrote:
>> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>>
>>>   I think -fpermissive should just be removed.
>>
>> The eon SPECmark will no longer build if we do that.
>
> Huh? I had been building eon without -fpermissive for
> a long time.

Thanks, you are right.  Apparently I didn't notice when -fpermissive
stopped being necessary...I am sure it once was.
Never mind.

Re: DR handling for C++

[Mark Mitchell]

Dale Johannesen wrote:

> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>
>>   I think -fpermissive should just be removed.
>
> The eon SPECmark will no longer build if we do that.

I suppose that's an issue, from a marketing perspective.  With my 
customer-service hat on, I care a fair amount, as I have customers who 
definitely want SPEC numbers.  With my GNU maintainer hat on, I don't 
care as much.

It may also be that eon requires a relatively small subset of 
functionality presently allowed with -fpermissive.  It may also be that 
if we do as I suggested (turn some pedwarns into errors, others into 
warnings, leave others as pedwarns) that we would be OK because the 
issues in question would become warnings, not errors.

My problem with -fpermissive is only tangentially that it allows us to 
compile bogus code; to me, the bigger problem is that it's yet another 
knob, and one that is C++ specific.  I see no reason why the basic 
warnings/errors/pedwarns structure from C should not also be used in C++.

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

Re: DR handling for C++

[Matt Austern]

On Sep 20, 2004, at 1:44 PM, Mark Mitchell wrote:

> Dale Johannesen wrote:
>
>> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>>
>>>   I think -fpermissive should just be removed.
>>
>> The eon SPECmark will no longer build if we do that.
>
> I suppose that's an issue, from a marketing perspective.  With my 
> customer-service hat on, I care a fair amount, as I have customers who 
> definitely want SPEC numbers.  With my GNU maintainer hat on, I don't 
> care as much.
>
> It may also be that eon requires a relatively small subset of 
> functionality presently allowed with -fpermissive.  It may also be 
> that if we do as I suggested (turn some pedwarns into errors, others 
> into warnings, leave others as pedwarns) that we would be OK because 
> the issues in question would become warnings, not errors.
>
> My problem with -fpermissive is only tangentially that it allows us to 
> compile bogus code; to me, the bigger problem is that it's yet another 
> knob, and one that is C++ specific.  I see no reason why the basic 
> warnings/errors/pedwarns structure from C should not also be used in 
> C++.

Isn't the fundamental problem that we're using pedwarns differently in 
the C and C++ front ends?  In the C front end you don't even see 
pedwarns unless you use a special compiler flag, and making them into 
errors requires an even more special compiler flag.  It's very odd that 
it means something so different in the C++ front end.

This is really going off into a different subject (pedwarn policy, not 
DR policy), but I'd suggest that we:
  1. Change the C++ front end's pedwarn defaults to match the C front 
end's policy.
  2. Remove -fpermissive, which #1 will render redundant.
  3. Go through our pedwarns and decide which ones should be errors, 
which ones should be warnings, and which ones really should just be 
pedwarns.

			--Matt

Re: DR handling for C++

[Mark Mitchell]

Matt Austern wrote:

> Isn't the fundamental problem that we're using pedwarns differently in 
> the C and C++ front ends?  In the C front end you don't even see 
> pedwarns unless you use a special compiler flag, and making them into 
> errors requires an even more special compiler flag.  It's very odd 
> that it means something so different in the C++ front end.
>
> This is really going off into a different subject (pedwarn policy, not 
> DR policy), but I'd suggest that we:
>  1. Change the C++ front end's pedwarn defaults to match the C front 
> end's policy.
>  2. Remove -fpermissive, which #1 will render redundant.
>  3. Go through our pedwarns and decide which ones should be errors, 
> which ones should be warnings, and which ones really should just be 
> pedwarns. 

Yes, that's exactly what I was trying to suggest.

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

Re: DR handling for C++

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

| On Sep 20, 2004, at 1:44 PM, Mark Mitchell wrote:
| 
| > Dale Johannesen wrote:
| >
| >> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
| >>
| >>>   I think -fpermissive should just be removed.
| >>
| >> The eon SPECmark will no longer build if we do that.
| >
| > I suppose that's an issue, from a marketing perspective.  With my
| > customer-service hat on, I care a fair amount, as I have customers
| > who definitely want SPEC numbers.  With my GNU maintainer hat on, I
| > don't care as much.
| >
| > It may also be that eon requires a relatively small subset of
| > functionality presently allowed with -fpermissive.  It may also be
| > that if we do as I suggested (turn some pedwarns into errors, others
| > into warnings, leave others as pedwarns) that we would be OK because
| > the issues in question would become warnings, not errors.
| >
| > My problem with -fpermissive is only tangentially that it allows us
| > to compile bogus code; to me, the bigger problem is that it's yet
| > another knob, and one that is C++ specific.  I see no reason why the
| > basic warnings/errors/pedwarns structure from C should not also be
| > used in C++.
| 
| Isn't the fundamental problem that we're using pedwarns differently in
| the C and C++ front ends?  In the C front end you don't even see
| pedwarns unless you use a special compiler flag, and making them into
| errors requires an even more special compiler flag.  It's very odd
| that it means something so different in the C++ front end.

I guess, the issue is to give a meaning to pedwarn() in C++ that would 
require a special flag to behave as in C, without totally screwing up
the whole program.  I have been under the impression that most of the
cases where we use pedwarn() in C++ are those where we substantially
deviate from the standard.  I don't know whether the same is true for C.

-- Gaby

Re: DR handling for C++

[Joseph S. Myers]

On Mon, 20 Sep 2004, Matt Austern wrote:

> Isn't the fundamental problem that we're using pedwarns differently in the C
> and C++ front ends?  In the C front end you don't even see pedwarns unless you
> use a special compiler flag, and making them into errors requires an even more
> special compiler flag.  It's very odd that it means something so different in
> the C++ front end.

If pedwarn() is executed, you see the diagnostic, for both C and C++ - no 
special flag is required.  -pedantic is only relevant to if (pedantic) 
pedwarn (...).

Every case where "pedantic" is checked represents some form of extension.  
Every such case should be documented as an extension, or the conditioning 
on pedantic removed.

pedwarn() is used where the standard requires a diagnostic but it hasn't 
been decided to make the relevant condition a hard error (or, in C++, it 
has been decided to permit the relevant condition under -fpermissive).  
Such cases should all also be documented (with details of the semantics 
assigned to the cases which the standard says are ill-formed but we 
permit) or removed (changed to hard errors).  (There may also be some 
cases where the standard permits the code to be rejected but does not 
require a diagnostic, where pedwarn() has been chosen.)

In both cases, and for both C and C++, one can document or remove any 
individual extension without needing to do all the others at the same 
time.

The name pedwarn() has been a bit confusing (because it suggests a link to 
-pedantic which isn't really there, the link being that -pedantic-errors 
turns pedwarns from warnings to errors), but I don't have a good 
suggestion for a less confusing name.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: DR handling for C++

[Paolo Bonzini]

> The name pedwarn() has been a bit confusing (because it suggests a link to 
> -pedantic which isn't really there, the link being that -pedantic-errors 
> turns pedwarns from warnings to errors), but I don't have a good 
> suggestion for a less confusing name.

-pedantic-errors is itself not very well named... maybe -Wextra-errors 
or something like that would be more suited now that -W has become -Wextra.

Paolo

Re: DR handling for C++

[Paolo Bonzini]

> The name pedwarn() has been a bit confusing (because it suggests a link to 
> -pedantic which isn't really there, the link being that -pedantic-errors 
> turns pedwarns from warnings to errors), but I don't have a good 
> suggestion for a less confusing name.

-pedantic-errors is itself not very well named... maybe -Wextra-errors 
or something like that would be more suited now that -W has become -Wextra.

Paolo

Re: DR handling for C++

[Joseph S. Myers]

On Tue, 21 Sep 2004, Paolo Bonzini wrote:

> > The name pedwarn() has been a bit confusing (because it suggests a link to
> > -pedantic which isn't really there, the link being that -pedantic-errors
> > turns pedwarns from warnings to errors), but I don't have a good suggestion
> > for a less confusing name.
> 
> -pedantic-errors is itself not very well named... maybe -Wextra-errors or
> something like that would be more suited now that -W has become -Wextra.

-Wextra-errors sounds like it turns the messages from -Wextra into errors.  
(The regular form for that in line with other similar options would be 
-Werror-extra - and any general warning control scheme would probably lead 
to such options corresponding to each warning option - but -Wextra-errors 
still sounds too similar to -Werror-extra.)

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: DR handling for C++

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> 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
patch. 

| 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
                                                         gdr@cs.tamu.edu
	 Texas A&M University -- Computer Science Department
	301, Bright Building -- College Station, TX 77843-3112

Re: DR handling for C++

[Mark Mitchell]

Gabriel Dos Reis wrote:

>| 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?)?
>  
>
Yes, that is what I am saying.  I do not think it's worthwhile for GNU 
C++ to have a C++98 mode that is separate from a C++03 mode.  Much of 
what has changed in C++03 is clarifications to C++98; in those cases, 
it's not possible to know what C++98 should have done with the code, 
because the actual C++98 standard did not say.

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

Re: DR handling for C++

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| 
| >| 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?)?
| >
| Yes, that is what I am saying.  I do not think it's worthwhile for GNU
| C++ to have a C++98 mode that is separate from a C++03 mode.  Much of
| what has changed in C++03 is clarifications to C++98; in those cases,
| it's not possible to know what C++98 should have done with the code,
| because the actual C++98 standard did not say.

If we do that, then we should probably align with the library too.
Otherwise it would become a very confusing situation.

-- Gaby

Re: DR handling for C++

[Mark Mitchell]

Gabriel Dos Reis wrote:

>Mark Mitchell <mark@codesourcery.com> writes:
>
>| Gabriel Dos Reis wrote:
>| 
>| >| 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?)?
>| >
>| Yes, that is what I am saying.  I do not think it's worthwhile for GNU
>| C++ to have a C++98 mode that is separate from a C++03 mode.  Much of
>| what has changed in C++03 is clarifications to C++98; in those cases,
>| it's not possible to know what C++98 should have done with the code,
>| because the actual C++98 standard did not say.
>
>If we do that, then we should probably align with the library too.
>Otherwise it would become a very confusing situation.
>  
>
I do not know if the DRs applying to the library are in the same 
category.  But, assuming that the C++03 library can be used with code 
expecting a C++98 library, then I would happily ignore C++98 for the 
library as well.

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

Re: DR handling for C++

[Matt Austern]

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

Re: DR handling for C++

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

[...]

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

[...]

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

well, isn't the last sentence in contradiction with the first paragraph? :-)

I believe C++98 + TC1, aka C++03 is a good thresold.  Anything
else should fall under -std=c++0x or -std=c++-experimental.

-- Gaby

Re: DR handling for C++

[Mark Mitchell]

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.

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

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

Re: DR handling for C++

[Matt Austern]

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

Re: DR handling for C++

[Mark Mitchell]

Matt Austern wrote:

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

I agree.  Thank you for educating me with respect to the history of this 
particular DR.

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

Re: DR handling for C++

[Jason Merrill]

On Mon, 20 Sep 2004 13:04:48 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

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

-fpermissive was a compromise between the desire for stricter conformance
checking and the desire for backwards compatibility with users' code, so
that users would be able to use newer compiler versions while they update
their code.  I still feel strongly that this is an important goal, but I'm
open to other ideas about how to implement it.

Jason