[red-knot] Empty tuple is always-falsy

[sharkdp]

Summary

Fix assignability of tuple[()] to AlwaysFalsy.

closes #17202

Test Plan

Ran the property tests for a while

[sharkdp]

The difference is that we now allow a fall-through to the catch-all "self is subtype of target" branch.

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[carljm]

I have a vague memory of intentionally making the opposite decision here.

I think the key question we need to ensure we are answering consistently is, do instances of subclasses of the built-in tuple type also inhabit our Type::Tuple types? My memory is that in other places we assume they can, but I would have to double-check. If they do, then we cannot say that the empty Type::Tuple is always-falsy, since the empty instance of a subclass of tuple could be truthy.

The potential problem with saying they do not, is that we do need to allow code like this:

def f(t: tuple[int, str]): ...

class MyTuple(tuple[int, str]): pass

f(MyTuple((1, "foo")))

In other words, if we say they do not, then our Type::Tuple can no longer correspond to the semantics of a tuple annotation.

[AlexWaygood]

I have a vague memory of intentionally making the opposite decision here.

Ah yes, astral-sh/ty#215 is still unresolved... I have a long reply in my head I've been meaning to write up there for a while :-) maybe I should set an explicit goal for myself to do that on Monday...

Anyway, I think the change to the code here is correct even if we disagree on the assertion being made in the mdtest!

[carljm]

Yes, I think the code change is correct, but we should add a TODO comment above the assertions (and maybe also above similar assertions for subtyping, if we have those already?) that we either need to special-case enforcement of Liskov on __bool__ and __len__ for tuple subclasses, or stop assuming that empty tuples are falsy and non-empty tuples are truthy.