Crystal: Indexable#reverse_map

[caspiano]

We have compact_map, flat_map... why not reverse_map?

Here's a gist with Array benchmarks... the benchmarking seems favourable.
I've got a PR with tests ready #8997

[straight-shoota]

I'm not sure about this. There are surely use cases for that.

We also have a lot more iteration methods than map. Why should we have reversed implementation for map only? There are a lot of methods in Indexable, Enumerable and Iterable which could have reversed implementeations.
We should discuss not only reverse_map but also reverse_reduce, reverse_index, reverse_each_*, reverse_join, reverse_cycle, reverse_group_by, reverse_flat_map and many more.
Maybe not all would be very useful, but it's hard to draw a line and certainly quite a few would seem at least as useful as reverse_map.

We already have efficient and composable iterators which can be used for that. A dedicated implementation is only significantly more performant for small sizes. The to_s specs reflect that, but I'm not sure why the i * 3 don't (supposedly a benchmarking error).

[caspiano]

I agree, where does one draw the line with these specialised methods? I personally had a use for an efficient reverse_map so I put together a PR.

reverse_reduce would be a handy method. I wouldn’t mind putting together a PR for the other reversed methods.

[jhass]

I feel like these are getting too specialized. At the same time it seems to be why we support an open class model, so anyone can reopen any class. I think these should proliferate as shard, collection_helpers or so. If we see some of these get used a lot we can then always revisit upstreaming them.

[asterite]

Yes, I don't think these are common enough to belong in the standard library. And if you need such things it shouldn't be that frequent so adding a reverse in between is usually fine.