This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: Fwd: C++ PATCH: PR 20599 (1/3)


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

(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
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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