Deprecate addIndex and addIndexRight and update map, reduce, etc, signatures

[Harris-Miller]

addIndexRight was added in 0.29.0 and is missing typing for it in types-ramda. Looking into how addIndex works, I couldn't help but notice that it doesn't seem necessary. All addIndex does is override calling the callback function with idx and list as the second and third parameter.

This begs the question, why can't this be the default behavior for map, reduce, etc?

While optional properties like this are not very FP, I think this case is different. The callback functions can always be called with the additional parameters, as they would only apply to the function passed if that function utilized them. This is how Array#map, etc, work natively. I believe the ramda functions for them should work the same.

The problem is that map, etc, support more than arrays. Personally, I don't think that this is a problem. From a typing perspective, there is nothing wrong with having a specific signature for the callback function depending on the type of the subject (list, object, or functor)

function map<A, B>(fn: (x: A, i: number, list: readonly A[]) => B, list: readonly A[]): B[];
function map<A, B>(fn: (x: A, prop: string, obj: Readonly<Record<string, A>>) => B, obj: Record<string, A>): B[];

Considering how Object.entries() yield the [i, value][] for arrays and [key, value][] for objects, the implementation for the above would actually be the same

FantasyLand implementations for Functor, Filterable, and the like, the 2nd and 3rd arguments would simply not apply.

I would also argue that we would not need to worry that map would take a function that could not apply correctly to all subject types. The way that a callback function is written would be specific for the subject type. Callback functions passed that only accept one argument would apply to all, while more than one would only apply to arrays and object. This is effectively the concept of wrapping with addIndex, simply without the extra step. I don't think it is unreasonable behavior for an overloaded function such as map and filter.

Was hoping to get some feedback on this idea from core team members

[CrossEye]

My simplest answer is to read #452 through. You can come back next week when you've finished. 😉

We added addIndex to avoid having additional functions such as map.idx, reduce.idx, filter.idx, which hid behind those main functions, with map et al doing dual duty as namespaces.

The classic example is

['1.0', '2.0', '3.0'].map(parseFloat) //=>  [1, 2, 3]
['1', '2', '3'].map(parseInt) //=>  [1, NaN, NaN]

because parseInt is interpreting the index argument as its radix parameter.

The trouble is that it simply doesn't belong for any input types except arrays, and certain other iterables. It doesn't apply to arbitrary Functors. Just saying that they can ignore it runs afoul our interest in simplicity.

[Harris-Miller]

@CrossEye thanks for digging up that issue from 2014. I figured my proposal had been discussed in the past, but couldn't find anything related after brief look in the MR and Issues history.

I had forgotten that R.map, and R.reduce support iterables that would not have either an index or a subject. So it is not just Functors that would be strange here.

How addIndex works with typescript, and your comment about if you did map.idx would main functions like map dual as a function and a namespace does segway into an additional issue that I'm been struggling with the type definitions. Though that I'll save to write up another day over on ramda/types

[CrossEye]

No digging necessary. The number 452 is burned into my brain. This was the first really contentious issue in Ramda. (Most of the others had to do one way or another with attempts to add a foldObject implementation.)