Contextually typed binding element initializers

[ahejlsberg]

This PR revises our contextual typing logic for initializers in destructuring declarations. Previously, the construct

let { a = xxx } = b;

had no contextual type for xxx. Now, xxx is contextually typed by b.a and the type inferred for a is consistent with the logically equivalent

let a = b.a ?? xxx;

with the exception that ?? substitutes xxx for both undefined and null whereas destructuring has no special behavior for null.

Some examples:

declare let x: { a: 0 | 1 | undefined };

let { a: a1 } = x;               // 0 | 1 | undefined
let { a: a2 = 0 } = x;           // 0 | 1
let { a: a3 = 2 } = x;           // number
let { a: a4 = 2 as const } = x;  // 0 | 1 | 2

Before this PR, the inferred type for a2 was number. Now, because the type of the initializer is a subtype of the contextual type 0 | 1 | undefined, no widening occurs. However, an initial value of 2 causes widening because it isn't a subtype. If this widening is not desired, a const assertion can be used to suppress it.

Fixes #35693.

[ahejlsberg]

@typescript-bot test this
@typescript-bot user test this
@typescript-bot run dt

[typescript-bot]

Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 529afa9. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 529afa9. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

Heya @ahejlsberg, I've started to run the extended test suite on this PR at 529afa9. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

[ahejlsberg]

@typescript-bot run dt
@typescript-bot user test this

[typescript-bot]

Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at f986e16. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at f986e16. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

[ahejlsberg]

RWC tests are clean. DT and Community test failures all appear to be preexisting conditions.

[ahejlsberg]

@RyanCavanaugh @weswigham This one is ready to merge. Want to take a look?

[weswigham]

Just to confirm: we no longer need to specially handle the widening of binding patterns whose initializer is an assertion expression because... our assumption is assertions can't occur in JS files? (/* @type */ casts should probably have counted though, even though they didn't) Or for another reason?

[ahejlsberg]

@weswigham The special case for a type assertion predated our support for fresh literal types. It was there just so you could force a binding element declaration not to widen. We neither need nor want that odd behavior anymore. Widening now follows naturally from the combined freshness of the destructured element type and the initializer type, i.e. a unit type stays fresh only of every occurrence of it in a union type is fresh.