<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 22, 2015 at 4:33 PM, Alexey Frolov <span dir="ltr"><<a href="mailto:alexfrolov1878@yandex.ru" target="_blank">alexfrolov1878@yandex.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Richard,<br>
<br>
I have some questions regarding issue described in <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_PR23915&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=1VmISgMqhIsHT5oMhRs8Z_3u7P9JK7B7gpSHuX09W8M&s=4jJmJEEsyz4kmY_jmjvJP8_buM65g-bB4Tv6Oi8KCOo&e=" rel="noreferrer" target="_blank">http://llvm.org/PR23915</a>.<br>
GCC header tr2/type_traits relies on compiler's support of __bases and __direct_bases type specifiers.<br>
I'd like to volunteer to implement this in Clang, but I need some guidance.<br>
Does the corresponding N2965 feature look like something the community will accept?<br></blockquote><div><br></div><div>There's a list of criteria for adopting extensions here: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_get-5Finvolved.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=1VmISgMqhIsHT5oMhRs8Z_3u7P9JK7B7gpSHuX09W8M&s=cTuPDylDaYJAzSxcec-FsdErncacxmGSfAnvUaLqozM&e=">http://clang.llvm.org/get_involved.html</a><br></div><div><br></div><div>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).</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div><div>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.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
What do you think of it?<br>
<br>
Thank you,<br>
Alexey Frolov<br>
=============<br>
Software Engineer<br>
Intel Compiler Team<br>
Intel<br>
</blockquote></div><br></div></div>