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

[Paolo Carlini]

Benjamin Kosnik wrote:

>> I'd like to help much more, but I'm in the middle of the 
>> __is_convertible_to work + yesterday finally committed the last 
>> tweaks to __has_nothrow_assign and right now I'm finally changing 
>> tr1/type_traits to exploit it and the other already available 
>> front-end traits...
>
> Cool.
>
> So, the testing issue is biting you too. What to do? Are you testing 
> both versions of the traits? I think this is probably the better way 
> to go, but more work.

At the moment, the implementation is fully conforming to tr1 + better 
QOI than the minimal one for the type properties thanks to the front-end 
support. Of course that means that some bits would not pass C++0x 
testing, like is_base_of.

> Anyway, I think we are on the same page, generally: those changes are 
> not minor and we have to figure out a strategy scaling well also to 
> cases of vastly different facilities (like random, even if, as 
> discussed privately, we can use the same underlying algorithms in both 
> cases, but that is another matter). About the details, at the moment I 
> lack a sufficiently accurate picture, I'd like to hear Doug again, 
> while I find the time to deepen my own understanding...
>
> Hmm. OK.
>
> Since we're both working on this, how should we stage this work?
>
> Should I check what I have in, and then proceed immediately to the 
> testsuite revamp? Once that is done I can add testcases for the new 
> traits. I would like to work on parallel stuff if possible.

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

Paolo.