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

[Benjamin Kosnik <bkoz at redhat dot com>]

> > +  template<typename _Tp>
> > +    struct has_trivial_default
> > +    : public integral_constant<bool, is_pod<_Tp>::value> { };
> > +
> > +  template<typename _Tp>
> > +    struct has_nothrow_default
> > +    : public integral_constant<bool, is_pod<_Tp>::value> { };
> >  
> the final names for those facilities are:
>
>    has_trivial_default_constructor
>    has_nothrow_default_constructor
>    has_trivial_copy_constructor
>    has_nothrow_copy_constructor
>
> (I'm going to change all of them to exploit the front-end traits, 
> already available).

Ah. So they are. Serves me right for going on R1. of this paper. Just so 
we are both looking at the same thing for future discussions, I'm going 
off of N2255=07-0115. Sound right?

Thanks!

> In general, these issue about TR1 vs C++0x are nasty. Other traits, for 
> example, are undergoing subtle semantic changes (for example, I 
> implemented __is_base_of consistently with the C++0x semantics and, as 
> you can see, for now, for TR1, I'm adjusting it a bit to the TR1 
> semantics); likewise for is_convertible_to, which will be different in 
> C+++0x (I'm currently working on the front-end support for it).

Yes. There is enough difference that

1) I don't think mixing C++0x and TR1 is wise
2) I begin to appreciate the dry humor of Howard's "minor modifications" 
 title...

Thanks for the more complete audit.

I also think our testing should take account of this divergence... what 
say you?

> I wish we manage to find a decently clean solution, which could also 
> mean separate files...

That's pretty much where I'm going..... What did you think of the 
_GLIBCXX_SUPPRESS_TR1 idea, and the plan for compat?

If the general idea for _GLIBCXX_SUPPRESS_TR1 seems sound, I'll go ahead 
and do it for special math too.

-benjamin