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

[Joe Buck]

I wrote, re hash_set and hash_map:
> > In the past, when we have deprecated code, the user gets a warning but
> > the code still builds.  By deprecating them *and* moving the headers,
> > the code simply breaks.  I don't understand why this is a good thing.
> > That is not the way we normally do deprecation.

On Fri, Oct 26, 2007 at 11:52:53PM -0500, Benjamin Kosnik wrote:
> Hmm. OK. 
> 
> I'm willing to concede on this one. There was no compile warning in a
> previous release for this item. Gerald has also asked about this as
> well.
> 
> How about I symlink backward/hash_map to ext/hash_map,
> and backward/hash_set to ext/hash_set?

That would make me happier, but I still have some concerns about the
deprecation (I would have preferred to just leave it, since the user
still has to say "ext/" and use other magic that makes its extension
status clear).  I suppose I could live with it. 

> Then, everybody is happy. Eventually, the symlink (n+2, say 4.5) can be
> killed.

Well, maybe not *happy*, but at least, not quite as pissed off. :-)

> > If not, are we really doing people a service by pushing them to TR1
> > before it is stable?
> 
> I'll correct the docs.

You mean, to stop warning people away from TR1?

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.