Is there a real utility for the .idx functions ? about ramda HOT 3 CLOSED

We are open to discussions about this, certainly. Neither of us loves this solution. But we really prefer that map not generally pass these unnecessary parameters. It's nothing to do with performance. (We'd get better if we didn't have to deal with this flag, honestly.) But it means that your callback function is generally very simple: function(item) :: item. And it avoids this sort of problem:

map.idx(parseFloat, ["1.1", "2.2", "3.3"]); //=> [1.1, 2.2, 3.3]
map.idx(parseInt, ["1", "2", "3"]); //=> [1, NaN, NaN] // WTF?

(This has to do with parseInt interpreting the index passed by map.idx as its radix parameter.)

It can be fixed by not using the additional parameters

map(parseInt, ["1", "2", "3"]); //=> [1, 2, 3]

This is not limited to our implementation. Here is the native version.

["1", "2", "3"].map(parseInt); //=> [1, NaN, NaN]

We simply feel that the main use of map involves working with the item alone. But we do want to be able to offer a version that also gives you the index and the whole array. That was the point of map.idx. But we'd love to hear alternatives that allow the simplest case to remain simple.

from ramda.

also, there are real use cases where having the index is very helpful, e.g. working with 2D array

from ramda.

I'm all for having the indexes ! I was advocating for the generalization of its passing to the parameters, but the parseInt and parseFloat examples are fairly convincing (even though in those particular cases, knowing that the prototype of these functions accept more arguments, a wrapper could do the trick, but, meh, okay :)

from ramda.