Call signature of take can prevent type inferrence when using curried signature

[TClark1011]

The current typing of the take function is this:

export function take(n: number): {
  (xs: string): string;
  <T>(xs: readonly T[]): T[];
};
export function take(n: number, xs: string): string;
export function take<T>(n: number, xs: readonly T[]): T[];

Right now, when you call the curried signature inside a pipe, the type of the array is not correctly inferred:

You can see the type inference is working correctly without the `R.take` call:

The solution is to change the curried signature for taking from an array to this:

export function take<T>(n:number): (xs: readonly T[]) => T[]

This also applies to takeLast.

I would be happy to open a PR for this.

[Harris-Miller]

The problem you have called out is not isolated to take and takeLast. It's also true for any curried function like this where the generic is set within the return type

For whatever reason, when you have a return type that is more than a single possibility, generics on those get immediately evaluated. I have a whole write up on it here: #54

The flip side of your fix is you lose support for the overload xs: string. However, I've been leaning more and more towards removing the extra overloads as my discussion suggests

Here are other alternatives that will solve you problem in the mean time: https://tsplay.dev/m0Voxw

[TClark1011]

My solution can still accommodate the string overload, we just have to add another signature for it, so the new declaration would look like this:

export function take<T>(n: number, xs: readonly T[]): T[];
export function take<T>(n:number): (xs: readonly T[]) => T[];
export function take(n: number, xs: string): string;
export function take(n:number): (xs: string) => string;

[TClark1011]

Okay I actually figured out a workaround that can handle both the string and array curried signature and allow the generic to be evaluated after the original call: https://tsplay.dev/N7QPGW

I understand this may not be the ideal solution, it was just an idea I had and thought it was worth mentioning.

[Harris-Miller]

@TClark1011 that's a fantastic solution for the issue with the generic. It won't solve the problem for all the functions that share this issue, but works for take and takeLast

#70