Consider re-ordering Array#reduce overloads in lib.d.ts

Example code:

type UnaryFunction = (arg1) => any;
type BinaryFunction = (arg1, arg2) => any;

let binaryFuncs: BinaryFunction[] = [];
let unaryFunc = arg1 => {};
let reduced = binaryFuncs.reduce((prev, next) => prev, unaryFunc);

// ACTUAL:
let f: UnaryFunction = reduced;     // ERROR binary not assignable to unary

// EXPECTED:
let f: UnaryFunction = reduced;     // OK - both lhs and rhs really are unary

The call to Array#reduce in the above example definitely returns a unary function, but the type system erroneously infers the return type as a binary function.

This seems to be caused by the declaration order of the two overloads of Array#reduce in lib.d.ts. If the declaration order is reversed, the problem is solved.

The two overloaded declarations in lib.d.ts are as follows:

reduce(callbackfn: (previousValue: T, currentValue: T, currentIndex: number, array: T[]) => T, initialValue?: T): T;
reduce<U>(callbackfn: (previousValue: U, currentValue: T, currentIndex: number, array: T[]) => U, initialValue: U): U;

The first overload matches the example with T=BinaryFunction, since it satisfies the compiler's assignability checks. So the second overload is never considered, even though it is a strictly better match, with T=BinaryFunction and U=UnaryFunction.

Would it be possible to swap the overload order for Array#reduce (and Array#reduceRight) in lib.d.ts to resolve this issue?

Simpler example:

let arrayOfObjs: {}[] = [/*...*/];
let countOfProps = arrayOfObjs.reduce((sum, obj) => sum + Object.keys(obj).length, 0);

This doesn't compile, tsc reports "Operator '+' cannot be applied to types '{}' and 'number'".

In fact the code is fine and runs fine.

tsc took the first overload since it works with T={}, so the second (correct) overload is not considered.

In general, the second overload will always be skipped if U is assignable to T (in this example, number is assignable to {}).

Swapping the order of the two Array#reduce overloads in lib.d.ts fixes this.

I believe it's safe to do this now -- the order we had was dependent on behavior that is no longer the case (ancient history, see http://typescript.codeplex.com/workitem/2352).

Wow, nice archaeological find 😄 Those were the days...

Glad this can now be resolved, and I really appreciate the effort the team takes in polishing these corner cases.

As a side not, I really dislike the argument ordering that TC39 chose for Array.prototype.reduce and Array.prototype.reduceRight. The seed should come first, not just because it makes type inference easier, but because it makes things more readable. Anyway, that decision is ancient history, but I wanted to rant about it.

Troy Gerwien (@yortus)

Just stumbled on this - look forward to this being resolved! For anyone else wondering what to do in the interim just supply the type parameter. So to take Troy Gerwien (@yortus) example, this:

let arrayOfObjs: {}[] = [/*...*/];
let countOfProps = arrayOfObjs.reduce((sum, obj) => sum + Object.keys(obj).length, 0);

Becomes:

let arrayOfObjs: {}[] = [/*...*/];
let countOfProps = arrayOfObjs.reduce<number>((sum, obj) => sum + Object.keys(obj).length, 0);

Taking PRs on this with the caveat we're still not 100% sure this is going to be an overall improvement, so reserving the right to reject it if it turns out to be bad on net.

~~I am on this PR.~~

Bilal Durrani (@bdurrani)

Bilal Durrani (@bdurrani) Just noticed that I closed the PR myself. Might had encountered some problem but forgot to update the comment here.

This appears to still be an issue. Anyone know why #11356 ended up closed? vilic?

agreed, we encounter this with typescript 3.7.3

const A = [1, '2', 3]
const str: string = A.reduce((str, a) => `${str} ${a.toString()}`, '')

which results in this compilation error:

Type 'string | number' is not assignable to type 'string'.
  Type 'number' is not assignable to type 'string'.

2     const str: string = A.reduce((str, a) => `${str} ${a.toString}`, '')
            ~~~

there is an easy enough workaround for now, i.e. A.map(_ => _.toString()).reduce(...), but this seems worth fixing?

agreed, we encounter this with typescript 3.7.3
const A = [1, '2', 3]
const str: string = A.reduce((str, a) => `${str} ${a.toString()}`, '')
which results in this compilation error:
Type 'string | number' is not assignable to type 'string'.
  Type 'number' is not assignable to type 'string'.

2     const str: string = A.reduce((str, a) => `${str} ${a.toString}`, '')
            ~~~
there is an easy enough workaround for now, i.e. A.map(_ => _.toString()).reduce(...), but this seems worth fixing?

An easier workaround.We provide the generic paramater here, so it matches the second overload.

const A = [1, '2', 3]
const str: string = A.reduce<string>((str, a) => `${str} ${a.toString()}`, '')

may be fix this with typescript 4.2.2?

Reorder Array#reduce overloads for better type inference (microsoft#7014

Reorder Array#reduce overloads for better type inference

fix(lib): reorder Array#reduce/reduceRight overloads in lib.d.ts

Navigation Menu

Repository navigation

Consider re-ordering Array#reduce overloads in lib.d.ts #7014

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Consider re-ordering Array#reduce overloads in lib.d.ts #7014

Description

Activity

yortus commented on Feb 11, 2016

RyanCavanaugh commented on Feb 12, 2016

yortus commented on Feb 12, 2016

aluanhaddad commented on Mar 11, 2016

johnnyreilly commented on Apr 4, 2016

RyanCavanaugh commented on Jun 9, 2016

vilicvane commented on Sep 25, 2016

1 remaining item

vilicvane commented on Oct 2, 2018

chriskrycho commented on Dec 19, 2019

starpit commented on Dec 20, 2019

Meowu commented on Feb 21, 2020

okmttdhr commented on Mar 31, 2020

SCWR commented on Sep 2, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions