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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
