Sebastian said:
If you could provide an alternative to better model the example code that would be great.
Here are three techniques that would work with the current proposal. ```python class QueryResult(Generic[T]): # Technique 1: Accept an explicit `value` parameter expecting the caller # to pass in an instance; they can pass `self` if that's the instance they # want to test. def is_empty1(self, value: "QueryResult[S]") -> TypeGuard[MissingQueryResult]: return value._data is None # Technique 2: Use a static method, expecting the caller to pass in "self" (or # whatever other instance they want to test) @staticmethod def is_empty2(value: "QueryResult[S]") -> TypeGuard[MissingQueryResult]: return value._data is None # Technique 3: Define it as a separate utility method, not part of the class. def is_empty_query_result(value: "QueryResult[S]") -> TypeGuard[MissingQueryResult]: return value.empty() ``` Do you agree that we want to support type guards that are instance or class methods? If so, then these functions will need to accept one explicit `value` parameter in addition to the implicit "self" or "cls" parameter. I think there's a case to be made for disallowing type guards as instance or class methods. That would mean that all type guard functions would need to be either a static method or a (non-method) function. Alternatively, we could allow type guards as instance/class methods but assume that the first implicit parameter (`self` or `cls`) is the value being tested. I don't think that multiple arguments is the problem here. I've come across a couple of cases in real code where I wouldn't have been able to use the TypeGuard mechanism if it was limited to just one argument, so I'm reluctant to place that limitation on it.