Bug 13041 – std.range.transposed consumes sub-ranges

void main() { import std.stdio, std.algorithm, std.range; auto M = [[[1, 2]], [[3, 4]]]; M.filter!(r => r.dup.transposed.walkLength).writeln; M.filter!(r => r.transposed.walkLength).writeln; } Output with dmd 2.066beta: [[[1, 2]], [[3, 4]]] [[[]], [[]]] I expected: [[[1, 2]], [[3, 4]]] [[[1, 2]], [[3, 4]]]

*** Issue 13824 has been marked as a duplicate of this issue. ***

Given how issue 17952 was resolved (we deprecated transposed being a forward range, as it would require dup'ing per save), I think we can close this as WONTFIX. Once Transposed.save is removed, we can update the docs to reflect that transposed may consume sub-ranges. I think this is just in the nature of transposed and how forward ranges are stored.

I wonder if there's any possibility of implementing .save for a random-access range, if the subranges are also random-access. In this case, we wouldn't need to consume the subranges at all, but can simply store a set of current indices to implement .transposed.

It certainly is possible. Note there is current work to update Transposed to use transverse to allow indexing https://github.com/dlang/phobos/pull/5805. I think we can go further building upon transverse, and its related option on how to treat the data. But it would be a strange relationship between transposed and its subranges. If the subranges were indexable, then Transposed can be a forward range, otherwise it can't. Seems unintuitive, and not sure it's worth all the effort. In other cases as well (if, for instance, the RangeOfRanges stores everything by value), then save could also be implemented. We may have a hard time detecting this because the relationship between Transposed and whether it's valid to make a copy is confusing and not well-established.