Too much of "any" about npm-ramda HOT 5 CLOSED

I agree with you in general that we should try to make the type checking as strict as feasible. Your proposal for the pair function is fine. The insert function is less obvious. The example function of Ramda fails in case of the more strict checking:

R.insert(2, 'x', [1,2,3,4]); //=> [1,2,'x',3,4]

Typescript can not infer type T from the definition as string conflicts with the list of numbers. It is a bit of an awkward example as it mainly shows that you can do weird things with javascript. So I would be in favor of the more strict approach and 1) correct the examples in the test file and 2) except that there will be some clashes in user's code where the 'freedom' of javascript is exploit which is in conflict with the more strict typing.

To be honest, up to now I haven't made a clear choice, but maybe now it is a good moment to do so. Any more thoughts/ideas on this issue?

from npm-ramda.

Regarding the "insert" example:
I absolutely agree that it is actually just an awkward thing allowed by javascript. What I am trying to say is that, I think it is better to make this awkwardness explicit, and have the strictly typed versions on the first place. So in your example it will look like this:

R.insert<any>(2, 'x', [1,3,4]);

Which means that if somebody needs awkwardness, no problem, just use "any" as the type explicitly. We can also have an overloaded versions with "any" for the cases where they will not override the strict typings.
Also, we can make this strict-to-loose typings even more gradual For example, additionally there could be a partly strict version with typed input but "any" output

insert<In, Out>(index: number, elt: In, list: Out[]): Out[];

//used like this
insert<string, any>(2, 'x', [1,2,3,4])

In this awkward case we will have at least a type-checked input, which is anyway better then nothing.

from npm-ramda.

@yazla I believe TS can't express an "array of single generic type". That's because JS has no tuples and you can't disallow array of mixed types by default because it will disable tuples.

from npm-ramda.

One more point regarding map, which is very important I think.
These definition:

map<T, U>(fn: (x: T) => U, obj: any): any; // used in functors

Is not that type safe for functors as it might be.
I believe it should be something like this:

map<T, U>(fn: (x: T) => U, obj: Functor<T>): Functor<U>;

I understand that defining Functors is out of Ramda's scope, but we can simply have a small interface with map method just for convenience(taking advantage of structural subtyping).
Basically my point is that if the function is supposed to work with functors, lets define that explicitly, not hiding that behind "any". We can still have "any" though, for just in case.

from npm-ramda.

@yazla: I've gone over all the typings again, and tried to strengthen inference using generics wherever possible, including for all noted examples here. If you have any more suggestions, they'd be welcomed, whether here or as PRs. Thanks for helping to make things better!

from npm-ramda.