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

[Alexey Frolov]

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
=============
Software Engineer
Intel Compiler Team
Intel

23.06.2015, 23:31, "Richard Smith" <richard at metafoo.co.uk>:
>  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