[v3] annex D 8 and 9 for C++0x

[Mark Mitchell]

Joe Buck wrote:

> Also, I had another question: do we expect the TR1 features, or some of
> them, to be absorbed into the regular standard, so that some future
> standards version will tell people to write <unordered_set> and not
> <tr1/unordered_set>, and drop the tr1 namespace as well?  And will we
> then get another round of deprecation?  The reason I ask is that a lot
> of long-lived code tries to support being compiled by many compilers,
> and I would like to argue in advance that making people keep changing
> the code is a bad idea.

I think that putting features into the compilers and the libraries --
even if marked experimental, beta, etc. -- encourages our users to rely
on them.  I don't think that users will necessarily thank us for
bringing them new features today if, after they adopt them, we make them
do work in future to keep using the features.

My opinion is that <tr1/unordered_set>, once present in a GCC release,
needs to be there essentially forever.  We can of course move its guts
into plain <unordered_set> and just have <tr1/unordered_set> include it.
We can issue a warning, but the warning ought to be:

  warning: to make your code ISO C++ conformant, use <unordered_set>

not:

  warning: <tr1/unordered_set> is deprecated and might go away

because it ought not go away.  In other words, the warning ought to be
telling the user that to work with other C++ compilers, they might want
to change their code -- not that G++ is going to change in a way that
breaks their code.

If we want to have an experimental branch of GCC to help the ISO C++
committee experiment with things that's fine.  If a distributor wants to
put that in their distribution that's fine too.  But, when an FSF
release comes out with a feature, that feature ought to be considered
permanent.

The Linux kernel has similar rules regarding the syscall interface.
GLIBC has similar rules regarding source and binary compatibility.  I
think we should have the same goals for the C++ front end and the C++
runtime library.  I fully recognize that these goals are not universally
achievable (although my hat is off to the Linux kernel and GLIBC
maintainers for the degree to which they've preserved compatibility over
time) and that the situation for C++ is harder, for various reasons.

But, I strongly believe that we should expect that once we release a
feature, people rely on that feature, and that we should thus keep it
working if reasonably feasible.

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