Call signature of `take` can prevent type inferrence when using curried signature about types HOT 4 OPEN

@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

from types.

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

from types.

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;

from types.

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.

from types.