[PATCH] D151952: [clang] adds `__type_pack_index` so we can get a type's parameter pack index

[Christopher Di Bella via Phabricator via cfe-commits]

cjdb added a comment.

In D151952#4392329 <https://reviews.llvm.org/D151952#4392329>, @rsmith wrote:

> Taking a step back for a moment: what is the intended use case for this? My concern is that most of the time you're going to want to make O(N) such queries into a pack of N elements, resulting in O(N^2) compile time, much like we regrettably get from uses of `__type_pack_element`. If we can avoid the regret in this case by providing a different intrinsic, perhaps we should do so. (For example, we could take two packs of types, and produce a sequence of integers giving the indexes of each of the first types in the second list, in O(N) time. And similarly we could add a `__type_pack_elements` that takes a pack of types and a pack of indexes and performs N indexing operations at once, in O(N) time, rather than having the program do it in O(N^2) time.)

When I wrote this I narrowly had `std::get<T>(tuple)` and `std::get<T>(variant)` in mind, both of which are linear in nature. Now that you raise this, I can see the described problem and will implement said feature (maybe there exists a world where `std::apply` can use this too?). Since we're doing this, it may also be worth checking that `T1s...` are unique in `T2s...`, which I'd intended to be a separate feature.

Can we get away with modifying `__type_pack_element` so that we don't need to introduce a new keyword, or should we have two for each?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151952/new/

https://reviews.llvm.org/D151952