This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: c++0x vs. tr1 type_traits, round 1
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.
Yeah.
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.
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.
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.
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.
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.
-benjamin