Types for functions like Array.prototype.reduce or RxJS's "scan" seem impossible

Bug Report

I searched, and couldn’t find a related issue (but I find it very unlikely one doesn’t exist). It seems like there should be something labeled “Design Limitation” or the like?

The basic problem is if you’re using a standard “reducer” callback pattern with a seed that is different from what your reducer returns the returned type is incorrect.

// The type of result is `number`, but should be `string`.
const result = [1, 2, 3].reduce((acc, value) => {
//                              ~~~~~~~~~~~~~~~~~
//                                 ^-- Error Here: "No overload matches this call"
    if (acc === null) {
        return '' + value;
    } else {
        return acc + ', ' + value;
    }
}, null);

console.log(result); // "1, 2, 3"
console.log(typeof result); // "string"

🔎 Search Terms

• is:issue is:open array reduce
• is:issue is:open reduce callback
• is:issue is:open reduce "No overload matches this call"
• is:issue is:open reduce label:"Design Limitation"

🕗 Version & Regression Information

Any version of TS, to TMK. Specifically tested in 4.2 and 4.4.4

• This is the behavior in every version I tried, and I reviewed the FAQ for entries as best I could. There’s apparently a LOT of them. I didn’t see anything related.

⏯ Playground Link

An example in the playground

💻 Code

// The type of result is `number`, but should be `string`.

const result = [1, 2, 3].reduce((acc, value) => {
//                              ~~~~~~~~~~~~~~~~~
//                                 ^-- Error Here: "No overload matches this call"
    if (acc === null) {
        return '' + value;
    } else {
        return acc + ', ' + value;
    }
}, null);

console.log(result); // "1, 2, 3"
console.log(typeof result); // "string"

🙁 Actual behavior

A type error, even though the compiled JavaScript is valid.

🙂 Expected behavior

No type error, result should be a type string, not number.

Related:

https://github.com/ReactiveX/rxjs/issues/6649

[DanielRosenwasser]

Our inference process is so fundamentally different here, but it does feel bad that when we have plain local statements, we’re able to dive into the body of this loop and know it’s either been set to string or null.

function foo(xs: number[]) {
    let acc = null;
    for (const value of xs) {
        if (acc === null) {
            acc = "" + value;
        }
        else {
            acc = acc + ", " + value;
        }
    }
    return acc;
}

I think at some point, I would like to pick @ahejlsberg’s brain to understand how control flow analysis deals with these sorts of circularities (it’s been a while for me, so I’ve largely forgotten). Maybe we could brainstorm on something that would work better with higher order functions like these. One issue with our inference process is that in our first pass going through arguments, we “lock in” inferences from expressions that aren’t “contextually sensitive” (e.g. callbacks). The null is the only non-contextually sensitive thing here, so it wins. We could play around with tweaks to this process, but

• it would be more complex
• it might be a lot more work on every overload
• it might break a huge chunk of code that exists today

[nmain]

This is an inference problem, but not a typing problem: https://www.typescriptlang.org/play?#code/PTAEBUAsFNQFwJ4AdYHsBmoBO0DOBXAGzlAEtdQADAO3wFsAjaLSgGlAfxN0lSIBMOsSrjhZS1AOaUAdAFgAUIoDGqaqOx4iJALygA2gEZ2AJnYBmALoyc-fMugAeWoUKgAPqFHipAPgAU-gCGysrsAG5BhPjQAJSgOr6gAN6KIKAZmVnZObkZAH6FRcUlhWlgeZVV2QB6ALR1oACiWFioWKAAEszQAFygAEQAcqigqOHMhKhBgnRBcMowFHCQ5KDKUYQDilmkmMGhCTp6LoTxqQp5OHD4WNSgAOQPoADUoJHR0ADcO5kAvqBoIRcLALldoDc7qAQspXo92M83h8Yj9Lv9FH92KdYqiVGpcKhCNAZFNJP4cARiDjQOkBsZQGZQOZtgpVOpCcTSf5ECgMJpKXBqbTvBJJAMgA