Skip to content

checker: use destructuring annotations for binding types - #14

Merged
nooga merged 3 commits into
mainfrom
ts-compat-destructuring-annotations
Aug 25, 2026
Merged

nooga merged 3 commits into
mainfrom
ts-compat-destructuring-annotations

Conversation

@nooga

@nooga nooga commented Jun 28, 2026

Copy link
Copy Markdown
Owner

Summary

Teach destructuring declarations to use explicit annotations as the binding source type.

  • Contextually type annotated array destructuring initializers before checking element bindings.
  • Use annotated object destructuring types when extracting optional properties and defaults.
  • Add a smoke script covering annotated tuple and object destructuring.
  • Refresh generated compliance docs.

Compat impact

Published TypeScript snapshot: 3341/4928 -> 3342/4928 (+1).

Against the exact local pre-change full dump used for this branch, the best observed push-hook result was 3340/4928 -> 3342/4928 (+2), with suite-order flakiness noted in the TypeScript runner.

Focused wins:

  • types/tuple/tupleElementTypes1.ts
  • controlFlow/controlFlowDestructuringDeclaration.ts

Validation

  • go build ./...
  • go build -o paserati-testtsc ./cmd/paserati-testtsc
  • go test ./tests -run TestScripts
  • Focused paserati-testtsc diffs for types/tuple and controlFlow
  • Full paserati-testtsc diff against the local pre-change dump

@mparrett

Copy link
Copy Markdown
Contributor

Findings apply to both #13 and #14: they point to the same commit/diff.

  • [P1] pkg/checker/checker.go:3459: array destructuring still derives binding and rest element types from valueType, not the annotation type. Because contextual typing is only applied when the initializer is an ArrayLiteral, annotated destructuring from any loses the declared tuple types:

    let pair: any = [1, "s"];
    let [a, b]: [number, string] = pair;
    a = "oops"; // accepted on the PR, should be a type error

    Rest has the same issue:

    let v: any = [1, "s"];
    let [a, ...rest]: [number, string] = v;
    rest = [1]; // accepted, but rest should be string[]
  • [P2] pkg/checker/checker.go:3615: object destructuring from tuple annotations now gets a new false positive because destructureType may be a TupleType, but this object-like check only accepts ObjectType, ArrayType, or Any.

    let v: any = [1];
    let { 0: x }: [number] = v; // PR errors: cannot destructure non-object type '[number]'

Verification run on the PR branch: go test ./tests -run TestScripts passed.

…lizers

The array destructuring path only used the declared annotation type when
the initializer was literally an array literal, falling back to the
initializer's own (possibly any/widened) type otherwise. Object
destructuring already resolved binding types from the annotation
unconditionally; bring array destructuring in line so e.g.
`let [a, b]: [number, string] = someAnyValue` types `a`/`b` from the
annotation instead of losing them to `any`.
@nooga
nooga marked this pull request as ready for review July 13, 2026 23:19
@nooga
nooga merged commit fbd21f6 into main Aug 25, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants