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

[Paolo Carlini]

Paolo Carlini wrote:

> If you can wait until late today, I have ready the changes to use 
> front-end support, the last days was waiting for Mark to approve a few 
> front-end bits...
>
> More generally, given that many names + semantics are going to be 
> different, I'd rather see an approach using separate files for C++0x 
> and TR1. Thus renounce to importing tr1/type_traits in the C++0x 
> implementation and not ifdefing stuff in and out, it's too much 
> already, and much more will be...

Actually, definitely better clearing the situation about TR1 vs C++0x 
first, *before* I change the traits to use front-end support in more 
places.... The reason is that unfortunately I'm just noticing that the 
semantics is subtly incompatible in more places than I thought: for 
example in tr1 all the has_trivial_* are by and large unspecified *but* 
must return the same value after remove_extent; also all the 
has_trivial_* >= is_pod and that is also incompatible with C++0x, where, 
if the type is const or reference, the value of has_trivial_assign is 
false anyway, irrespective of PODness. A mess, in short.

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.

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.

Paolo.