You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently represent "known instances" (e.g. special forms like typing.Literal, which are an instance of typing._SpecialForm, but need to be handled differently from other instances of typing._SpecialForm) as an InstanceType with a known field that is Some(...).
This makes it easy to handle a known instance as if it were a regular instance type (by ignoring the known field), and in some cases (e.g. Type::member) that is correct and convenient. But in other cases (e.g. Type::is_equivalent_to) it is not correct, and we currently have a bug that we would consider the known-instance type of typing.Literal as equivalent to the general instance type for typing._SpecialForm, and we would fail to consider it a singleton type or a single-valued type (even though it is both.)
An instance type with known.is_some() is semantically quite different from an instance type with known.is_none(). The former is a singleton type that represents exactly one runtime object; the latter is an open type that represents many runtime objects, including instances of unknown subclasses. It is too error-prone to represent these very-different types as a single Type variant. We should instead introduce a dedicated Type::KnownInstance variant and force ourselves to handle these explicitly in all Type variant matches.
The text was updated successfully, but these errors were encountered:
We currently represent "known instances" (e.g. special forms like
typing.Literal
, which are an instance oftyping._SpecialForm
, but need to be handled differently from other instances oftyping._SpecialForm
) as anInstanceType
with aknown
field that isSome(...)
.This makes it easy to handle a known instance as if it were a regular instance type (by ignoring the
known
field), and in some cases (e.g.Type::member
) that is correct and convenient. But in other cases (e.g.Type::is_equivalent_to
) it is not correct, and we currently have a bug that we would consider the known-instance type oftyping.Literal
as equivalent to the general instance type fortyping._SpecialForm
, and we would fail to consider it a singleton type or a single-valued type (even though it is both.)An instance type with
known.is_some()
is semantically quite different from an instance type withknown.is_none()
. The former is a singleton type that represents exactly one runtime object; the latter is an open type that represents many runtime objects, including instances of unknown subclasses. It is too error-prone to represent these very-different types as a singleType
variant. We should instead introduce a dedicatedType::KnownInstance
variant and force ourselves to handle these explicitly in allType
variant matches.The text was updated successfully, but these errors were encountered: