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: Fwd: C++ PATCH: PR 20599 (1/3)

Mark Mitchell wrote:

Just a quick note on this thread: I'm not ignoring it. However, I may not be able to comment on the what-should-we-do-about-C++0x for another day or two, as I want to write something coherent, and I have other commitments.

Here is my current thinking:

* From the point of view of FSF releases of GCC, it is not an objective for GCC to be an experimental implementation platform for programming languages. Instead, the FSF releases are supposed to be compilers for people to use for production software development. (I'm not claiming to speak for the FSF on this point; rather, it's my opinion, as a GCC SC member, about what the FSF's position ought to be.)

Therefore, we want to implement features because we think they will serve our users well over time, not because they will advance a standards process. (In many cases, those goals will not be in conflict; but, in the cases where they are, our users should win. And, of course, I'm all for people adding experimental features to GCC on branches, distributing those branches, etc.; my comments here are purely in the context of FSF releases.)

We should be sensitive to the fact that adding features and then changing them is going to make some of our users very unhappy.

* At the same time, it is in GCC's best interest to be the best compiler available, across all axes, and that includes supporting new programming language features. If we can gain a competitive advantage by being the first to deliver a new feature, then we should.

* Therefore, building on the suggestions in this thread, my suggestion is that we:

(a) add C++0x features only with a command-line option (off by default, for now) so that users have to explicitly request the features,

(b) document that option in the manual as enabling experimental features and warning people that C++0x is subject to change, and that the GCC Gimplementation will track the actual standard, without regard for backwards compatibility with previous GCC releases,

(c) refrain from adding a feature until it is actually part of the WP, so that "feature oscillation" is minimized.

What do people think of that suggestion?

Mark Mitchell
(650) 331-3385 x713

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