[ty] Allow protocols to participate in nominal subtyping as well as structural subtyping

Author: AlexWaygood

crates/ty_python_semantic/resources/mdtest/protocols.md

@@ -2090,6 +2090,61 @@ static_assert(is_subtype_of(TypeOf[satisfies_foo], Foo))
 static_assert(is_assignable_to(TypeOf[satisfies_foo], Foo))
 ```
 
+## Nominal subtyping of protocols
+
+Protocols can participate in nominal subtyping as well as structural subtyping. The main use case
+for this is that it allows users an "escape hatch" to force a type checker to consider another type
+to be a subtype of a given protocol, even if the other type violates the Liskov Substitution
+Principle in some way.
+
+```py
+from typing import Protocol
+from ty_extensions import static_assert, is_subtype_of
+
+class X(Protocol):
+    x: int
+
+class YProto(X, Protocol):
+    x: None = None  # TODO: we should emit an error here due to the Liskov violation
+
+class YNominal(X):
+    x = None  # TODO: we should emit an error here due to the Liskov violation
+
+static_assert(is_subtype_of(YProto, X))
+static_assert(is_subtype_of(YNominal, X))
+```
+
+A common use case for this behaviour is that a lot of ecosystem code depends on type checkers
+considering `str` to be a subtype of `Container[str]`. From a structural-subtyping perspective, this
+is not the case, since `str.__contains__` only accepts `str`, while the `Container` interface
+specifies that a type must have a `__contains__` method which accepts `object` in order for that
+type to be considered a subtype of `Container`. Nonetheless, `str` has `Container[str]` in its MRO,
+and other type checkers therefore consider it to be a subtype of `Container[str]` -- as such, so do
+we:
+
+```py
+from typing import Container
+
+static_assert(is_subtype_of(str, Container[str]))
+```
+
+This behaviour can have some counter-intuitive repercussions. For example, one implication of this
+is that not all subtype of `Iterable` are necessarily considered iterable by ty if a given subtype
+violates the Liskov principle (this also matches the behaviour of other type checkers):
+
+```py
+from typing import Iterable
+
+class Foo(Iterable[int]):
+    __iter__ = None
+
+static_assert(is_subtype_of(Foo, Iterable[int]))
+
+def _(x: Foo):
+    for item in x:  # error: [not-iterable]
+        pass
+```
+
 ## Protocols are never singleton types, and are never single-valued types
 
 It *might* be possible to have a singleton protocol-instance type...?

crates/ty_python_semantic/src/types.rs

@@ -1613,16 +1613,13 @@ impl<'db> Type<'db> {
                 callable.has_relation_to_impl(db, target, relation, visitor)
             }),
 
-            (Type::ProtocolInstance(left), Type::ProtocolInstance(right)) => left
-                .interface(db)
-                .extends_interface_of(db, right.interface(db), relation, visitor),
-
-            // A protocol instance can never be a subtype of a nominal type, with the *sole* exception of `object`.
-            (Type::ProtocolInstance(_), _) => C::unsatisfiable(db),
             (_, Type::ProtocolInstance(protocol)) => {
                 self.satisfies_protocol(db, protocol, relation, visitor)
             }
 
+            // A protocol instance can never be a subtype of a nominal type, with the *sole* exception of `object`.
+            (Type::ProtocolInstance(_), _) => C::unsatisfiable(db),
+
             // All `StringLiteral` types are a subtype of `LiteralString`.
             (Type::StringLiteral(_), Type::LiteralString) => C::always_satisfiable(db),
 

crates/ty_python_semantic/src/types/call/bind.rs

@@ -1058,17 +1058,9 @@ impl<'db> Bindings<'db> {
                             // `tuple(range(42))` => `tuple[int, ...]`
                             // BUT `tuple((1, 2))` => `tuple[Literal[1], Literal[2]]` rather than `tuple[Literal[1, 2], ...]`
                             if let [Some(argument)] = overload.parameter_types() {
-                                let Ok(tuple_spec) = argument.try_iterate(db) else {
-                                    tracing::debug!(
-                                        "type" = %argument.display(db),
-                                        "try_iterate() should not fail on a type \
-                                            assignable to `Iterable`",
-                                    );
-                                    continue;
-                                };
                                 overload.set_return_type(Type::tuple(TupleType::new(
                                     db,
-                                    tuple_spec.as_ref(),
+                                    &argument.iterate(db),
                                 )));
                             }
                         }

crates/ty_python_semantic/src/types/instance.rs

@@ -107,13 +107,36 @@ impl<'db> Type<'db> {
         relation: TypeRelation,
         visitor: &HasRelationToVisitor<'db, C>,
     ) -> C {
-        protocol
-            .inner
-            .interface(db)
-            .members(db)
-            .when_all(db, |member| {
-                member.is_satisfied_by(db, self, relation, visitor)
-            })
+        let structurally_satisfied = if let Type::ProtocolInstance(self_protocol) = self {
+            self_protocol.interface(db).extends_interface_of(
+                db,
+                protocol.interface(db),
+                relation,
+                visitor,
+            )
+        } else {
+            protocol
+                .inner
+                .interface(db)
+                .members(db)
+                .when_all(db, |member| {
+                    member.is_satisfied_by(db, self, relation, visitor)
+                })
+        };
+
+        // Even if `self` does not satisfy the protocol from a structural perspective,
+        // we may still need to consider it as satisfying the protocol if `protocol` is
+        // a class-based protocol and `self` has the protocol class in its MRO.
+        //
+        // This matches the behaviour of other type checkers, and is required for us to
+        // recognise `str` as a subtype of `Container[str]`.
+        structurally_satisfied.or(db, || {
+            if let Protocol::FromClass(class) = protocol.inner {
+                self.has_relation_to_impl(db, Type::non_tuple_instance(class), relation, visitor)
+            } else {
+                C::unsatisfiable(db)
+            }
+        })
     }
 }
 

crates/ty_python_semantic/src/types/property_tests.rs

@@ -217,8 +217,6 @@ mod stable {
 mod flaky {
     use itertools::Itertools;
 
-    use crate::types::{KnownClass, Type};
-
     use super::{intersection, union};
 
     // Negating `T` twice is equivalent to `T`.
@@ -313,16 +311,4 @@ mod flaky {
         bottom_materialization_of_type_is_assigneble_to_type, db,
         forall types t. t.bottom_materialization(db).is_assignable_to(db, t)
     );
-
-    // Any type assignable to `Iterable[object]` should be considered iterable.
-    //
-    // Note that the inverse is not true, due to the fact that we recognize the old-style
-    // iteration protocol as well as the new-style iteration protocol: not all objects that
-    // we consider iterable are assignable to `Iterable[object]`.
-    //
-    // Currently flaky due to <https://github.com/astral-sh/ty/issues/889>
-    type_property_test!(
-        all_type_assignable_to_iterable_are_iterable, db,
-        forall types t. t.is_assignable_to(db, KnownClass::Iterable.to_specialized_instance(db, [Type::object(db)])) => t.try_iterate(db).is_ok()
-    );
 }