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

Mark Mitchell mark@codesourcery.com
Fri Sep 29 00:34:00 GMT 2006

Doug Gregor wrote:

> One part I'm not clear about is whether you envision this to be a single 
> flag (e.g., -std=c++0x, -std=gnu++0x) or whether it should be multiple 
> flags (-experimental-rvalue-ref, -experimental-decltype, etc.). 

I expected it to be a single flag, for the same reasons you've stated.

I think that means that we've reached consensus on the policy.  There 
don't seem to have been any counter-suggestions.  So, I will pass the 
proposed policy up to the SC shortly.

> Since the policy we're agreeing on excludes variadic templates from 
> consideration, I'd like to see this patch discussed on its own merits. 

To some extent, the point of having a policy is to eliminate the need to 
discuss things on their own merits. :-) The smiley is there because, of 
course, one doesn't want to slavishly follow most policies.

I happened to see Steve Adamczyk and P.J. Plauger this week, and I 
discussed variadic templates with them.  (Doug already knows these 
folks, but for other people reading along, Steve is at EDG, which makes 
a C++ front end, and P.J. is at Dinkumware, which makes a C++ runtime 
library.  Steve and P.J. are both incredibly technically knowledgeable 
about C++ and also work directly with customers.)  We're all agreed that 
variadic templates are a useful feature, and that they can substantially 
simplify a C++ standard library.  However, we also agreed that it would 
be best to wait until this feature is in the WP before providing it in a 
release so as to avoid conflicts between our tools.

So, my position is that we should stick with the policy that I proposed. 
  I think that, based on rather strong feedback from users, G++ could 
better serve its users by maintaining compatibility over longer periods 
of time.  In contrast to G++/libstdc++, you can build Dinkumware's 
library with G++ going back to G++ 3.0, and you can configure EDG's 
front end with all manner of backwards-compatibility options.  I don't 
want to go that far, but I think that the policy I proposed is a 
reasonable compromise that encourages us not to get too far ahead of the 

(An alternative approach is to intentionally implement ahead, lobby hard 
for that implementation to completely define the standard, and hope to 
gain a competitive advantage by being ahead of the game.  But, I don't 
think that strategy is likely to win for G++.)

For avoidance of doubt: all this is just my opinion, and my {RM,SC}-ness 
carries no special weight here; if my fellow C++ maintainers disagree, 
they have two votes to my one. :-)  Even if they do agree, that doesn't 
prevent an implementation of variadic templates from going on a branch, 
which would permit people to gain experience with the feature.

I'm sorry to be in the position of disagreeing with you, since I think 
you've implemented a very nice feature, and implemented it well.  I hope 
that you don't take my comments personally, as they're not intended that 
way at all.  If you go back and read the list archives, you'll find that 
I've argued against most GNU extensions over the years.  Generally, 
other people are a bit more accepting of extensions than I, so you 
should probably keep lobbying. :-)

Mark Mitchell
(650) 331-3385 x713

More information about the Libstdc++ mailing list