scan() definition

[Karql]

Hi!

I've just started my journey with rxjs ;)
Reading overview I've gone to scan() documentation.
After some lecture I thought "why seed is type of T|R"

I checked the source code:
https://github.com/ReactiveX/rxjs/blob/6.2.1/src/internal/operators/scan.ts

Ok seed is type T|R in case of use first value of source when is not passed.
But imo this is correct behavior when T == R

When T != R it can case errors like this:

Imo to avoid this seed should be mandatory when T != R.
It imiples on change in definition from:
export function scan<T, R>(accumulator: (acc: R, value: T, index: number) => R, seed?: R): OperatorFunction<T, R>;
to:
export function scan<T, R>(accumulator: (acc: R, value: T, index: number) => R, seed: R): OperatorFunction<T, R>;

What do you think? Should I create PR for this?

[bafolts]

Requiring users to pass the initial value of their seed seems like the safest route. If not requiring users to provide a value for the first seed the final scan really gets T | R.

export function scan<T, R>(accumulator: (acc: T | R, value: T, index: number) => R, seed?: R): OperatorFunction<T, R>;

If not requiring an initial value for the seed undefined for the original value would make sense. It is strange to me that the seed becomes of type T in this final case.

[cartant]

@bafolts If a seed isn't specified, the initial value passed as the accumulator will be the first received value - i.e. a T. This mirrors the behaviour of Array.prototype.reduce.

@Karql Until the tests include proper type expectations - see #3823 - I don't think any changes should be made to the signatures. Unless there is a clear bug. (Even then, there can be unexpected consequences - see #3841.) Also, regarding the scan and reduce signatures, there was some discussion in #2897 that might be related to this.

[bafolts]

What is included does match what typescript is using for typing reduce.

https://github.com/Microsoft/TypeScript/blob/master/src/lib/es5.d.ts#L1090

Something like #3823 would be helpful.

[BioPhoton]

@cartant I believe we can close this issue please correct me if not and in the best case suggest a way to proceed with this