Proposal: Removal of certain overloads (RFC)

[Harris-Miller]

Some overloads have particularly bad support with typescript. Let's look at filter for example

The filter(fn)(listOrObject) variety can be typed in 2 ways. First is the current way:

export function filter<A, P extends A>(
  pred: (val: A) => val is P,
): {
  <B extends A>(list: readonly B[]): P[];
  <B extends A>(dict: Record<string, B>): Record<string, P>;
};

The problem with this way is that typescript always chooses the last overload when you pass a function as an argument. That means that doing this

const getNameAndFilter = pipe(
  prop('name'),
  filter(isNotNil)
);

Only works if obj.prop returns an object and not an array. if you flip the overload order, you can only use an array and not an object.

The second way to type this is in the current update MR

export function filter<T>(
  pred: (value: T) => boolean,
): <C extends readonly T[] | Record<string, T>>(collection: C) => C extends readonly any[] ? T[] : Partial<C>;

This does allow for either arrays or objects in the above example, however, there is a new problem:

const thing = pipe(
  filter(isNotNil) 
);

Although isNotNil is generic, it collapses to unknown. I believe this is because the type definition does calculates with T so typescript has to choose a minimum value for it, and that value in this case is unknown

Playground example

This is contrary to if we just had this as the definition:

export function filter<T>(pred: (value: T) => boolean): (list: T[]) => T[];

Where the T is "transferred". See this playground example

Now the final problem, if we overload this working version with support for objects

export function filter<T>(pred: (value: T) => boolean): {
  <U extends Record<PropertyKey, T>>(obj: U extends T[] ? never : U): U;
  (list: T[]): T[];
};

The T doesn't transfer anymore again. It collapses to unknown. (Final playground example)

The Proposal

What I would like to propose is to remove the extra overloads for functions like this. The problem is that if we keep object support, we can't even use it in its most common use-case, and the array support doesn't work when the fn passed to filter is a generic.

And since to use the object overload you'd have to do this anyways:

const thing = pipe(
  <U extends object>(obj: U) => filter(isNotNil, obj) 
);

It doesn't make sense to keep the object overload

So filter should only have this definition:

export function filter<T>(pred: (value: T) => boolean): (list: T[]) => T[];

I believe that this gives the best possible support for the most common use-case, supplementing when you want to filter on an object via an inline arrow function

filter and map are to 2 main culprits of this, but there are others that I am looking into as well

[lax4mike]

Would it be possible to have two separate declarations like this?

export function filter<T>(pred: (value: T) => boolean): (list: T[]) => T[];
export function filter<T>(pred: (value: T) => boolean): <U extends Record<PropertyKey, T>>(obj: U) => U

It would use the first if given an array, and the 2nd if given an object?

[lax4mike]

Hm, I'm messing around in the playground. Would something like this work to infer the return type?

type ArrayOrObj<V> = V extends any[] ?  V[] : Record<PropertyKey, V>

declare function filter<T>(pred: (value: T) => boolean): <U>(arrayOrObject: U) => ArrayOrObj<U>;

[Harris-Miller]

That detaches value: T from U. And because typescript isn't doing anything with T, it remains generic. But then you can pass anything in as U, and you get no type-safety. Because U doesn't have to match T[] or Record<string, T>

[lax4mike]

Hmm, you're right. 🤔 What if we tied them together like this?

declare function filter<T>(pred: (value: T) => boolean): <U>(arrayOrObject: U) => U extends T[] ? U : U extends Record<PropertyKey, T> ? U : never;

r1 and r2 are of type never whereas r3 is correctly Person[] and r4 is correctly Record<PropertyKey, Person>

[lax4mike]

Or we can do the extends part in the generic declaration, which gives better errors

declare function filter<T>(pred: (value: T) => boolean): <U extends T[] | Record<PropertyKey, T>>(arrayOrObject: U) => U;

[Harris-Miller]

Those do both work, however we cannot support filter<T, TF extends T>(pred: (value: T) => value is TF) with either of these methods. See playground: https://tsplay.dev/Wobnjm

And having diverging behaviors between passing a predicate that are typed to return boolean versus the type narrowing value is TF would be very odd in usage

[Harris-Miller]

@lax4mike found another instance of this, see: #69

Because of how take is overloaded, the generic type collapses and is unknown, removing the overload for xs: string would fix it just the same as I pointed out for filter. This is making me lean really hard towards moving forward with this proposal

[Harris-Miller]

@rbuckton thank you for all your feedback on DefinitelyTyped/DefinitelyTyped#68695 and suggestions. I'm pinging you here because I think you'll find this discussion quite interesting, and was hoping to solicit some feedback and recommendations from you

Thanks in advanced!