Array method definition revamp: Use case collection

We’ve gotten numerous issue reports and PRs to change the methods of Array, particularly reduce, map, and filter. The built-in test suite doesn’t cover these very well, and these methods interact with each other and the surrounding contextual type in fairly subtle ways.

@jablko has done a great job at #33645 collecting a variety of issues into a single PR; we need to augment this PR (or something like this) with a proper test suite so we can be sure about what’s being changed.

I’d like to create a clearinghouse issue here to collect self-contained (I CANNOT POSSIBLY STRESS THIS ENOUGH, SELF-CONTAINED, DO NOT IMPORT FROM RXJS OR WHAT HAVE YOU) code samples that make use of the array methods.

Please include with your snippet:

• Compiler settings
• Compiler version you were testing with
• The expected behavior (examples that should and should not produce errors are both useful)
• No imports or exports; snippets need to be self-contained so that we can put them into our test suite without extra complications

Once we’ve established a critical mass of code snippets, we can start combining the existing PRs into an all-up revamp and assess its impact to real-world code suites to figure out which changes don’t result in unacceptable breaking changes.

ｓｅｌｆ－ｃｏｎｔａｉｎｅｄ

[ExE-Boss]

I believe that .map(…) operations on tuple types should still produce a tuple type.

[RyanCavanaugh]

From #24579: flat should, well, flatten. Tested on 3.8-beta with target: ESNext, strict on

declare let arr: [[number, boolean], string];
let x0 = arr.flat(0); // Should be [[number, boolean], string] or (number | boolean | string)[]
let x1 = arr.flat(1); // Should be [number, boolean, string] or (number | boolean | string)[] 
let x2 = arr.flat(2); // Should be [number, boolean, string] or (number | boolean | string)[]