C++ PATCH: PR 20599 (1/3)

[Mark Mitchell]

> At the same time, I (still) believe we badly need a global strategy for 
> the C++0x features, for those features adding keywords, 
> incompatibilities, and all the others

We definitely need such a strategy.  I think that this is a big enough 
deal that we should try to get a meeting of the minds here, and then get 
explicit buy-in from the Steering Committee.  I would imagine the SC 
would sign off on our plan -- but I thin we should run it by them, since 
the decisions we'll make could have a pretty wide-reaching effect on GCC 
users.

In particular, while it seems reasonable to add a c++0x mode, and 
document it is an explicitly unstable and possibly varying in future, 
experience tells us that people will build code relying on whatever the 
current implementation is and that those people will be unhappy when the 
implementation changes.  The problem of source incompatibility from 
version to version, in both C and C++, was something that was raised at 
the GCC Summit, and is also something that has been expressed to me as a 
concern by many of CodeSourcery's customers.

It's easy to say "well, we warned the users, it's their problem" -- but 
I don't think that's necessarily how we best convince people to prefer 
G++ to competing alternatives.

Also, without casting any aspersions whatsoever on Doug or his patches, 
previous substantial changes to the C++ front end have sometimes 
unintentionally resulted in oscillations in what is or is not accepted. 
    (I am personally responsible for much of the damage, including bugs 
that I still need t fix for the upcoming 4.2 release, so I'm in no way 
criticizing anybody.)

So, I'm somewhat hesitant to incorporate changes before the standard is 
sufficiently final.  At the same time, I of course think that providing 
support for the latest and greatest form of the C++ language in G++ 
would be a very good thing.

I'm not sure how to balance these two things.  One approach would be to 
put 0x code on a branch, and merge it wholesale at some point in the 
future.  Another would be to explicitly disable the 0x code, unless 
enabled with a configure option.  Another would be to print a warning on 
every compilation when the enable-0x option was used.  All of these 
options are bad, either because they are ineffective, inconvenience 
users, or inconvenience developers -- or all of the above.

Thoughts?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713