backwards headers vs. C++0x

[Benjamin Kosnik]

> If it's not hard to keep these headers, why not do it?  We know that
> there are a lot of users that have large codebases and are resistant to
> changing them.  The free software codebases (e.g., KDE) are not
> representative of industrial codebases.  If maintaining compatibility
> makes it hard to move forward and implement new features, that's a good
> argument for removing things -- but just tidiness isn't.

Sadly, we won't really know until removal who is still using these 
headers. It's my suggestion to probe this area a bit: my last suggestion 
allowed for reinstatement, which I think is completely reasonable. We'll 
at least get rid of the unused ones this way.

I think there are other good arguments for removal besides just 
tidiness, or standing in the way of new features.

I think it's foolish to have a standard library that doesn't deprecate 
weaker interfaces in a meaningful way. In the case of the headers under 
discussion, some of them have  been unused for 10 years or more.

In addition, many of the backwards headers are not really being 
maintained at the moment (say the hash_set bits), have known issues, and 
clearly superior alternatives exist (std::tr1::unordered_set). Anything 
that's actually considered relevant and useful is already available as 
an extension: see ext/slist and ext/rope for instance.

With C++0x, a substantial number of new interfaces are being introduced, 
and perhaps a new set of older interfaces will deprecated.(As above, I 
would propose moving ext/hash_set to backwards/hash_set. Martin clearly 
thinks that others deserve this treatment, and I would probably go along 
with the usual suspects.).

The time is now to think clearly about the total set of interfaces that 
will be supported w/ C++98/03 and C++0x flavors. I think removing the 
current backwards contents is a reasonable starting point, provided that 
there exists a mechanism to put back backwards headers that are still 
actively used.

best,
-benjamin