DetachHead

i dont get it, `Left() + Right()` is a `str` in basedpyright and at runtime so what's the issue?

any reason why the error should be on the usage instead? having to account for every possible type in the definition would be annoying

It would probably need to be a setting so users can decide for themselves, similar to what I did with `strictGenericNarrowing`

sounds like my `@implements` decorator hack is relevant here? https://github.com/DetachHead/basedpyright/issues/775#issuecomment-2807917771

@beauxq i agree with your logic, i feel the same way when arguing against circular imports. i always tell people they can typically be avoided if you just think a...

was there any limitation with basedmypy's version without the special form? ```py from __future__ import annotations def f(a: object) -> a is int: assert isinstance(a, int) ```

context for anyone wondering why there's no error when assigning a `str` to `self.a`, it's because `a`'s type is actually inferred as `int | str` but it displays the wrong...

interestingly, the same can't be said about `ClassVar`s Code sample in [basedpyright playground](https://basedpyright.com/?typeCheckingMode=all&reportUnannotatedClassAttribute=false&code=GYJw9gtgBALgngBwJYDsDmUkQWEMoDCANgIYDOZAaiSADRQgCmAboyUQPrwKMCwAUAIEBjUhSgBBAFwCocqCSmExVGlAC8UAIxD%2B8qAAFR5MhEYwAFmAAms%2BdcbAowABSiyAShl7989wDoSDSgAIhIQ3QEJf1cPXSZWdi5ERhcJFw9AjzkAYigAI3JGawQ4ECQ0CxglVBh6EABXFBgsRiUyGBAgA) ```python from typing import ClassVar, reveal_type class A: a: ClassVar = 1 @classmethod def f(cls): cls.a =...

workaround: use [`S110`](https://docs.astral.sh/ruff/rules/try-except-pass/) instead. though it has a different error message, it seems to be pretty much the same rule except it also covers this case as well. perhaps `SIM105`...