Contextual type from destructuring binding for `Array#reduce` produces bad errors

[RyanCavanaugh]

TypeScript Version: 3.6

Search Terms: array reduce destructuring binding tuple

Code

const [oops] = [1, 2, 3].reduce((accu, el) => accu.concat(el), []);

Expected behavior: Should be OK (oops gets value 1 at runtime)

Actual behavior: It's not good. The empty array in the second reduce argument gets inferred as an empty tuple and things go downhill quickly.

1. On the call accu.concat(el), we get the error "Type number is not assignable to ConcatArray<never>"
2. The oops identifier gets errored with "Initializer provides no value for this binding element" because we think the return tuple is empty.

Playground Link: Linky

Related Issues: ?

[RyanCavanaugh]

Not immediately clear what to do. Add an overload to reduce that special-cases an empty reduce array? Add a conditional type somewhere? Change something about destructuring/tuple interaction? @ahejlsberg ?

[ajafff]

Probably related to #20681 as type parameters in return position are inferred from the contextual type.

[fatcerberus]

I thought [] was usually inferred as never[], not a tuple? TS only usually infers tuples with as const, I thought. Is it because of the destructuring?

[ahejlsberg]

@RyanCavanaugh The one that really doesn't make sense is this:

const [oops] = [1, 2, 3].reduce((acc: number[], e) => acc.concat(e), []);  // Error

We correctly infer number[] from the type annotation on acc, yet we still issue the "Initializer provides no value for this binding element and the binding element has no default value" error on oops. The error is issued by logic in array literal checking where we artificially pad the length of an array literal when it is contextually typed by a binding pattern. This logic doesn't really seem necessary anymore, I believe it goes back to the days where tuples weren't fixed length. I'll see what we can do to revise.

Meanwhile, the error in the original example sort of makes sense. All we have to infer from is the expression [] and it is contextually typed by a tuple (in the sense that the destructuring wants element 0 from the result and not just the array element type).