
I propose allowing `MyType: TypeAlias[T]` *in addition to* the existing `MyType: TypeAlias = T` or `MyType: TypeAlias = "T"` I understand that this is listed under Rejected Ideas, but I assume this was rejected as a syntax instead of the PEP syntax. I am suggesting that *both* forms be allowed. It will be faster at runtime because `"MyType"` will not be added to the current namespace. It will be stored in `__annotations__` in the current namespace in either case. It allows `T` to be a forward reference, when using future annotations import. I don't understand why TypeAlias cannot be used in a function scope. If it has to do with the value assigned to the alias variable, this would not apply with the new form, because there is no assignment. The type alias is just an unitialized variable. A type checker will treat the non-assignment form as equivalent to the assignment form. That is, `MyType` is considered to be an alias for `"T"` or `T`. The name `MyType` should be able to be imported to another module (but with a forward reference evaluated in the current module, not the importing module), or used as a type or part of a type in other contexts. To avoid the objection that it "looks like an uninitialized variable," I say that it *is* in fact an uninitialized variable syntactically, but semantically it is a type alias. The docs should make this clear. To avoid ambiguities with further assignments to `MyType`, the type checker should consider `TypeAlias` as Final. Thus, for `MyType` in a given scope, there will be exactly one of the above forms of alias declaration. When a type checker examines the name `MyType` it should ignore its being uninitialized when the type is a `TypeAlias[T]` and evaluate it as `T`.