Skip to content

Strict record and tuple subtyping#1460

Merged
soutaro merged 3 commits intomasterfrom
tuple-type
Jan 7, 2025
Merged

Strict record and tuple subtyping#1460
soutaro merged 3 commits intomasterfrom
tuple-type

Conversation

@soutaro
Copy link
Owner

@soutaro soutaro commented Jan 7, 2025

  • The length of the tuple types must be same
  • Record type with additional key cannot be a subtype of another record type

@soutaro soutaro added the area/core Issues related to the type checker core label Jan 7, 2025
@soutaro soutaro added this to the Steep 1.10 milestone Jan 7, 2025
@soutaro soutaro merged commit 1cbceaf into master Jan 7, 2025
@soutaro soutaro deleted the tuple-type branch January 7, 2025 08:26
@soutaro soutaro added the Released The PR is already included in a published release label Mar 11, 2025
rhiroe added a commit to rhiroe/steep that referenced this pull request Feb 26, 2026
When an array literal appears in an if-branch and the expected return type
is a union of tuple types (e.g. [":", ".#"] | [".#", ":"]), the type
checker was incorrectly inferring [::String, ::String] instead of the
correct literal tuple type.

The root cause: #try_tuple_type returns a Pair even when the inferred type
doesn't match the given tuple hint. Previously, the first non-nil pair was
accepted unconditionally, so ['.#', ':'] tried against hint [":", ".#"]
produced [::String, ::String], which was accepted instead of trying the
next hint [".#", ":"].

Fix: validate each candidate pair with a subtype check against the specific
tuple hint. If no candidate passes the check, fall back to the first
candidate (to preserve the FalseAssertion diagnostic for cases like
[1, ""] #: [1, "", bool]).

Fixes the regression introduced by soutaro#1460 (Strict record and tuple
subtyping).
rhiroe added a commit to rhiroe/steep that referenced this pull request Feb 26, 2026
When an array literal appears in an if-branch and the expected return type
is a union of tuple types (e.g. ["yes", "ok"] | ["no", "error"]), the type
checker was incorrectly inferring [::String, ::String] instead of the
correct literal tuple type.

The root cause: #try_tuple_type returns a Pair even when the inferred type
does not match the given tuple hint. Previously, the first non-nil pair was
accepted unconditionally, so ["no", "error"] tried against hint ["yes", "ok"]
produced [::String, ::String], which was accepted instead of trying the
next hint ["no", "error"].

Fix: validate each candidate pair with a subtype check against the specific
tuple hint. If no candidate passes the check, fall back to the first
candidate (to preserve the FalseAssertion diagnostic for cases like
[1, ""] #: [1, "", bool]).

Fixes the regression introduced by soutaro#1460 (Strict record and tuple
subtyping).
rhiroe added a commit to rhiroe/steep that referenced this pull request Feb 26, 2026
When an array literal appears in an if-branch and the expected return type
is a union of tuple types (e.g. `["yes", "ok"]` | `["no", "error"]`), the type
checker was incorrectly inferring `[::String, ::String]` instead of the
correct literal tuple type.

The root cause: `#try_tuple_type` returns a `Pair` even when the inferred type
does not match the given tuple hint. Previously, the first non-nil pair was
accepted unconditionally, so `["no", "error"]` tried against hint `["yes", "ok"]`
produced `[::String, ::String]`, which was accepted instead of trying the
next hint `["no", "error"]`.

Fix: validate each candidate pair with a subtype check against the specific
tuple hint. If no candidate passes the check, fall back to the first
candidate (to preserve the `FalseAssertion` diagnostic for cases like
`[1, ""]` `#: [1, "", bool]`).

Fixes the regression introduced by soutaro#1460 (Strict record and tuple
subtyping).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/core Issues related to the type checker core Released The PR is already included in a published release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant