Re: c++0x vs. tr1 type_traits, round 1

[Paolo Carlini <pcarlini at suse dot de>]

Hi Benjamin,

> > I think the only sane approach to this problem is keeping the 
> > implementations completely separate, use in the tr1 implementation 
> > the front-end support minimally, renounce to some QoI. Like it is 
> > now, basically. Therefore add a new file for C++0x, where I can use 
> > the front-end support anywhere it helps.
>
> Yes.
>
> FYI the "new file for C++0x" already exists.... see 
> include/std/type_traits.

I know. I think we are agreeing that it should be changed to never 
include <tr1/type_traits>, instead provide a separate implementation, 
which, in practice, will start by copying the current tr1 one. What 
about tr1/type_traits_fwd.h? Probably we should copy/adjust it too.

> This is what I added decay, enable_if, etc to.
>
> That part of my patch seems correct. The _GLIBCXX_SUPPRESS_TR1 bits 
> seem not to be.
>
> I believe it is actively a danger to include both tr1/type_traits and 
> c++0x's type_traits. It should not be too much work to show ambiguity 
> between function template calls that include explicitly qualified tr1 
> arguments.
>
> How do we prevent that if they are separate files? I suppose we could 
> just do a macros check for the TR1 macro guard and #error.

I have to think about this a little more... I was under the impression 
Doug had some ideas. Otherwise, let's just do something simple as a 
start, let's just allow one or the other and error, I agree. In any 
case, we have to deal with this problem, we can't delay it further, 
type_traits is only the tip of the iceberg...

> > One final note, to clarify what I mean by "the situation will become 
> > worse": PODness in C++0x is not the same that in C++03! Really if we 
> > don't want to get crazy, I think we should keep the tr1 
> > implementation as-is, then add a separate file for the C++0x one, 
> > starting the same as the tr1 one, and then gradually improved to the 
> > finest details of C++0x.
>
> Ok. Then, do you agree that a place to start in on this is to start 
> adding in the "requirements" bits to the current TR1 type_traits 
> testing? Then we should be able to do easier copies and such when we 
> add C++0x testing.

Requirements bits are always welcome.

> I'm just trying not to stomp on your work. If you'd like, I can try to 
> do this today so that we're both on the same page for tomorrow.

At this point there is no risk of stomping me, in the sense that, until 
we clear the TR1 vs C++0x issue, I can't meaningfully change anything in 
the TR1 implementation.

Therefore I would ask you to go ahead with something straighforward, as 
we discussed above: set-up a separate implementation of type_traits for 
C++0x by copying the current TR1 one, adjusting the names of those 4 
traits discussed between yesterday and today, adding the new traits. 
Then when you are done, I will be do immediately a couple of changes on 
top: simplify is_base_of to just use __is_base_of; use the front-end 
traits in all the has_trivial_* and has_nothrow_*. Those things I can't 
do in the TR1 implementation.

> In the meantime, I will try to write up a more coherent compatibility 
> post, with the examples I've been using to think about this.

Ok.

Thanks,
Paolo.