I agree with Nir Schulman, I also don't think that producing a runtime warning is something that the type system should be responsible for. I would never expect a decorator from `typing` to produce a warning. As Eric Taut mentioned, there is a fairly popular library called 'Deprecated', that's already capable of handling this, and it's doing so quite well. I do get that people might not love the idea for having to use 2 decorators on all deprecations though. For that reason, I think it'd be great if we could do something like: T = typing.TypeVar("T", bound=Callable) def deprecate(func: T) -> typing.deprecated(T): ... or the much more natural, though currently declined idea of going with typing.Deprecated[T]. This would allow the 'Deprecated' library to add any runtime functionality to the decorator, and the typing system to easily recognize that any decorated function is now deprecated. On top of that, it allows users to handle deprecation decorator implementations on their own, which could be quite useful, as someone might prefer something like: deprecated("Use X instead", date=datetime(2023, 5, 10)) rather than a version based deprecation. If needed, runtime support could then be added outside of the typing module, with something like warnings.deprecated, which would be defined like in my example above, but I don't think it's a good idea to introduce too much runtime logic into typing features. I'm also very much for supporting variable deprecations, as currently, typed libraries that define some type aliases as a part of the public API are forced to make changes that simply can not currently be deprecated in any way. Allowing users that are importing these type aliases to see a deprecation warning from a type-checker would finally allow such libraries to properly handle deprecations. I wrote a bit more about this here: https://mail.python.org/archives/list/typing-sig@python.org/thread/E3BUVIKOD...