[cfe-dev] Clang is missing __bases and __direct_bases support (regarding PR23915)

[Richard Smith]

On Mon, Jun 22, 2015 at 4:33 PM, Alexey Frolov <alexfrolov1878 at yandex.ru>
wrote:

> 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
> __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
> =============
> Software Engineer
> Intel Compiler Team
> Intel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150623/f19c5ec2/attachment.html>