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

[Benjamin Kosnik]

> > 3) The hash extensions are used, no doubt, but there is a way
> > forward here as well. (See my emails).
> 
> Here is where I disagree with you, and am puzzled by your "no doubt".
> For a decade, they were the only STL-compliant hash classes widely
> available.  Thanks to STLport, they work with many compilers.  They
> are *very* widely used.  By having them in ext/, we clearly flag that
> they are an extension.
> 
> 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.

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?

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

> If not, are we really doing people a service by pushing them to TR1
> before it is stable?

I'll correct the docs.

best,
-benjamin