[PATCH] D144503: [WIP][STLExtras] Allow `llvm::enumerate` to enumerate over multiple ranges

[Jakub Kuderski via Phabricator via llvm-commits]

kuhar added a comment.

In D144503#4142824 <https://reviews.llvm.org/D144503#4142824>, @dblaikie wrote:

> In D144503#4142807 <https://reviews.llvm.org/D144503#4142807>, @kuhar wrote:
>
>> Can you give an example? I don't see how this would work. My starting point is that I would like to enable this: `for (auto [Idx, X, Y, Z] : ...(Xs, Ys, Zs)...)`.
>>
>> If we tried to compose `enumerate` and `zip_equal`, we would end up with `flatten` used like this: `for (auto [Idx, X, Y, Z] : flatten(enumerate(zip_equal(Xs, Ys, Zs))))`. Here flatten would have to a `map_range`-style range adaptor, and I think we would lose `it.index()`?
>
> Yep, something along those lines - yep, would lose a nice spelling for `index` on the iterator (it'd just be a tuple) - but given structured bindings, do people much want/need that naming anyway?

I see. I think in this specific case the ergonomics make this work in real world. We have a considerable amount of code in MLIR and IREE that iterates over multidimensional stuff in lockstep, and it's nice to have a concise and safe way to manage that. I don't think that `flatten` achieves that given the total amount of nesting. Instead, one could unpack the values in the first statement inside the loop like so:

  for (auto [Idx, Val] : enumerate(zip_equal(...))) {
    auto [X, Y, Z] = Val.value()

Another issue I see is unintentionally unpacking a single element in generic code -- a single range can contain tuple values, and I don't think we can tell this apart from `zip(...)` without checking the range/iterator type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144503