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

[Joe Buck]

> > But I am worried that you are being much too aggressive about
> > deprecation. 550 broken Debian packages is not a good sign.  Have you
> > checked with your colleagues about just how big a job you're handing
> > them, getting Fedora or RHEL6 to work with 4.3?

On Fri, Oct 26, 2007 at 05:29:27PM -0500, Benjamin Kosnik wrote:
> I appreciate the concern you show for me and my colleagues. However,
> your lack of faith is a bit depressing.

I have faith that we will come up with a satisfactory resolution to the
issues (and Martin has since said that the "550" number includes manyu
other issues).  I apologize for conflating more than one issue.  However,
I still have an objection.

> 1) Debian has 550 build issues right now due to header/include
> streamlining. All the packagers, irregardless of distro, are fixing
> this stuff up. This issue preceded any patch of mine, but for the
> record, I am in support of this streamlining work and consider it a
> good thing. 

Understood.  Please substitute the numbers Richard Guenther reported for
openSUSE: the ext/ change alone causes 62 build failures.

> 2) The pre-iso C++ include issue is easy to fix, the changes are largely
> mechanical and well documented, and has been warned about for six
> years. 

I accept getting rid of the pre-iso include files like <iostream.h>, as
they have been warned about in the past.

> 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.

> The point is not usage, but clearly
> communicating from the maintainers to the users what is considered
> deprecated now and in the future: the fact that you've been taken so
> completely by surprise when the file is marked as it is, documented
> as such, and the alternatives so obvious, indicates the depth of the
> challenge here and the possible advantages of my approach. These changes
> were made in a way that was consistent with other changes, like the
> split of extensions into namespace __gnu_cxx. 

I am well aware of how to port code that uses the ext containers to the
tr1 containers.  But even now, we avertise tr1 as highly unstable and
experimental.  For all we know, the committee will move headers from
tr1 into the top level include directory at some point.  Does everyone
have to change their code again?  What about the labor to get code to
work with many different compilers and compiler versions?  Rats' nests
of #ifdefs are not fun.

Are you planning to change and commit to ABI stability for TR1?
If not, are we really doing people a service by pushing them to TR1
before it is stable?

> Perhaps you would be willing to document or explain some of these issues
> for the gcc online docs?

This implies that I'm just supposed to accept and write up what you did.
I have an official role to make sure that GCC serves the needs of the
users.  I could accept most of the changes, but I have a problem in
particular with the hash changes.  I might even accept a deprecation
warning, with clear documentation on how to turn it off.  But moving
the headers from ext to backward has not been justified adequately.

> Your last post about montone was helpful, and
> if you combine it with Jonathan Wakely's musings (very interesting as
> well) about typedef templates and backward compatible typedefs, my
> details about compat we'd really be getting somewhere. It would
> probably make more sense if somebody besides me can explain the
> approach taken and outline alternative approaches.
> I've been trying to be clear and accurate but am unimpressed with the
> job I've been doing so far.

I'll think about it.