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

[Richard Guenther]

On 9/25/06, Doug Gregor <dgregor@cs.indiana.edu> wrote:
>
> On Sep 25, 2006, at 9:58 AM, Howard Hinnant wrote:
> > I would prefer something more like:
> >
> > g++ my_source.cpp -enable_rvalue_refs -enable_variadic_templates -
> > enable_static_assert -lboost -lAcme
>
> Whereas I would prefer, e.g.,
>
>         g++ -std=c++0x -lboost -lAcme
>
> Otherwise, users need to track exactly what we're done in each minor
> release to try out these features. For instance, with GCC 4.3.0 users
> might need to write:
>
>         g++ my_source.cpp -enable_rvalue_refs -enable_variadic_templates -
> enable_static_assert -lboost -lAcme
>
> Then for GCC 4.3.1 we implement more of the C++0x working draft, so
> we now have:
>
>         g++ my_source.cpp -enable_rvalue_refs -enable_variadic_templates -
> enable_static_assert -enable-decltype -enable-auto -lboost -lAcme
>
> Then maybe the committee changes its mind, so we yank a feature [*]
> from GCC 4.3.2 and get:
>
>         g++ my_source.cpp -enable_rvalue_refs -enable_variadic_templates -
> enable-decltype -enable-auto -lboost -lAcme
>
> Now users need to determine the patch level of g++ to enable C++0x
> features. If we have one flag, the variance in features from version
> to version will be queried through feature-test macros (supplied by
> the compiler). Users just decide whether they want the C++0x features
> or not.
>
> When C++0x goes out the door, we add -std=c++09 (just guessing <g>)
> for the new standard and deprecate -std=c++0x. It's not much
> different from what we're already doing with -std=c9x and -std=c99.

Well, this exactly points at the problem we are facing with adding
extensions for future parts of the C++0x standard.  We do _not_ want to
encourage "persistent" use of the new features (which can and will
vanish at any point without backwards compatibility).

This practically means the compiler should just provide _one_
-std=c++0x-draft (or whatever name) and _not_ provide preprocessor
macros for features included in the particular release.  This avoids
giving false promises about stability of these language extensions.

Uses in gccs own standard library implementation are "fine" in the
sense that at the point of implementation we know the feature set
we can rely on.  Of course something like #pragma gcc C++0x would
be needed to enable the language features for a subset of a translation
unit.  Or we would need to provide fallback implementations conforming
to the current C++ standard, which would be against the purpose of
using the new features in our library implementation.  Of course special
care needs to be take to remain ABI and Interface compatible between
implementations where required.

I still suggest somebody goes forward and creates a C++0x branch and
implements the suggested changes.

Thanks,
Richard.