Clang is missing __bases and __direct_bases support (regarding PR23915)

Hi Richard,

I have some questions regarding issue described in http://llvm.org/PR23915.
GCC header tr2/type_traits relies on compiler's support of __bases and __direct_bases type specifiers.
I'd like to volunteer to implement this in Clang, but I need some guidance.
Does the corresponding N2965 feature look like something the community will accept?

It looks like this should be implemented as a UnaryTransformType (like __underlying_type is implemented), but we should transform type-argument into a some kind of a pack of base (or direct base) types.
What do you think of it?

Thank you,
Alexey Frolov

Hi Richard,

I have some questions regarding issue described in http://llvm.org/PR23915
.
GCC header tr2/type_traits relies on compiler's support of __bases and
__direct_bases type specifiers.
I'd like to volunteer to implement this in Clang, but I need some guidance.
Does the corresponding N2965 feature look like something the community
will accept?

There's a list of criteria for adopting extensions here:
http://clang.llvm.org/get_involved.html

The first thing to observe is that GCC's std::tr2::* stuff is non-standard.
While there were proposals to add features to a C++ TR2, there was never
such a standard (nor even a working draft for such a standard, as far as
I'm aware), and never a formal WG21 motion to adopt N2965. Further, GCC's
std::tr2::bases and ::direct_bases do not conform to the design in N2965 --
as far as I can see, they're a prototype implementation of a revised design
that was never proposed for standardization (the namespace is different,
the result is not in a tuple<...>, and not even a tuple-like type; I'm not
sure what else is different).

I'm not seeing a significant user community for this extension -- your bug
report is the first of its kind, and I cannot find any open-source code
that uses this extension. Can you provide evidence of a desire for this
extension from Clang users?

Then, there's the design of the intrinsics themselves: there will be
significant implementation complexity introducing another kind of "source"
of unexpanded parameter packs, especially one that could appear outside of
a template. This could easily be avoided by a different intrinsic design
(for instance, we could imagine a __bases(tuple, T) that expands to
tuple<T_base_1, T_base_2, ...>). Obviously we can't change what libstdc++
did here, but if we wanted to support this in libc++, I would suggest
ditching GCC's intrinsics in favor of something simpler.

There's work going on in the C++ Reflection SG to define facilities similar
to this, but no concrete proposal just yet. Based on the current evidence,
I'm inclined to say that we should wait for a formal proposal from that
group before implementing anything in this area.

It looks like this should be implemented as a UnaryTransformType (like

Hi Richard,

Thank you for the prompt and irrefragable answer!
The only evidence of a desire would be for Clang to be able to compile GCC header tr2/type_traits.
I understand the criteria and can as well see that this is not yet worth adopting.
Thanks for help again!

Best regards,
Alexey Frolov