types inferring problem with scan operator #3150
Description
I'm having a problem when using scan with 2 different type for item and accumulator/seed on ts 2.5+ (didn't try older versions).
You can see it here : https://stackblitz.com/edit/ts-fn-overload-bug?file=test.ts
of('0').pipe(
scan((acc, str) => acc + parseInt(str), 0)
);gives the following error :
Argument of type 'UnaryFunction<Observable, Observable>' is not assignable to parameter of type 'UnaryFunction<Observable, Observable>'.
Types of parameters 'source' and 'source' are incompatible.
Type 'Observable' is not assignable to type 'Observable'.
Type 'string' is not assignable to type 'number'.
Even if scan has a signature matching that use case (the last one) :
function scan<T>(accumulator: (acc: T, value: T, index: number) => T, seed?: T): MonoTypeOperatorFunction<T>;
function scan<T>(accumulator: (acc: T[], value: T, index: number) => T[], seed?: T[]): OperatorFunction<T, T[]>;
function scan<T, R>(accumulator: (acc: R, value: T, index: number) => R, seed?: R): OperatorFunction<T, R>;As it's shown on the stackblitz, order seems to matter so it's most likely a ts bug.
But looking closely on those types, @NaridaL pointed out that the last signature should be enough to cover all cases. Indeed R can totally be inferred with the same type as T or T[].
So the question is : is there any reason for having those subtype signatures ? especially since now it seems to create a bug ?
P.S: Couldn't find a corresponding ts issue but didn't do much digging
P.S2: I think the same applies for reduce.