Latest Results
[ty] treat properties as full structural types (#23925)
## Summary
Fixes https://github.com/astral-sh/ty/issues/3032
The bug there was that type relation judgements between two
`PropertyInstance` ended up falling back on both sides to using
`KnownClass::Property`, meaning that we would always consider any two
`PropertyInstance` (even with entirely different getters/setters) as
equivalent.
Fixing this bug required more clearly deciding on the semantics of a
`PropertyInstance` type. Either it is a singleton type representing
exactly one property object, or else it is a structural type with getter
and setter members and full structural subtype relations accordingly.
The existing code sort of leaned towards the singleton understanding,
but that interpretation isn't sustainable consistently with the current
Salsa-interned implementation of `PropertyInstanceType`. If we create
two different properties in our Python code, but with the same getter
and setter type, those will become the same Salsa-interned
`PropertyInstanceType`, and thus necessarily treated as equivalent. In
other words, we can't truly treat a type as a singleton type unless it
is either known to be interned at runtime (e.g. `None`), or its
Salsa-interned attributes include a `Definition` or similar
differentiator (e.g. class and function literals).
So I instead chose to go the other direction, and implement full
structural type relations for `PropertyInstanceType`, which isn't that
complex since they only have two possible attributes.
## Test Plan
Added an mdtest which fails on main representing the user-observable
behavior where a union of property instances collapsed.
Added comprehensive mdtests for type relations between property
instances. Active Branches
#23926+5%
#237970%
#239200%
© 2026 CodSpeed Technology