*Default ordering*
I strongly disagree with changing this for a few reasons: - I think keeping this similar to function signatures is the best way to do this as it’s much easier to teach. You can just imagine it expanding the class e.g.: ```py class Foo(Generic[T, DefaultIntT]): ... ``` Would expand to (assuming the args would be unpacked) ```py class Foo: def __class_getitem__(cls, T, DefaultIntT = int) -> GenericAlias: ... ``` - Rust will fail to compile code like where a non-default follows a default https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=89533c099f99d1d721c3ea5b44461728, you might think this is part of Rust not allowing unknowns at runtime (it's actually because type parameters are positional) but this is also something that typescript doesn’t allow https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD28A8AVaBeaA7ArgWwCMBT... - This would allow something like dict[str] == dict[str, Any] which I think is problematic as this doesn’t currently work and I don’t think it should. The point about the default being Any vs Unknown is a good one but, I’m not sure how this would work at runtime.
*Constrained TypeVars*
Good idea done.
*Use of generics in default*
As I mentioned, this is something that Rust supports and TypeScript also supports (which I didn’t even realise when writing my reply) this so maybe it’s not that bad to implement? *Function defaults*
If this is required, what about more complicated parameter type annotations that involve a TypeVar with a default type argument, such as `T | None` or `List[T]`?
The signature default should have to be compatible with the annotation default: `T | None` => (_: T | None = T) or (_: T | None = None) `List[T]` => (_: List[T] = []) This is however, something that TypeScript and Rust don’t enforce (though Rust doesn’t have default parameters). I might reconsider this but I’d be interested to hear your additional concerns over this maybe that would sway me.
What about cases where the TypeVar appears for multiple input parameters?
Maybe it should just require one of the arguments to have a default. I don’t see a use case for this if there isn’t a default signature argument present, maybe I’m missing something though. *TypeVarTuple*
Can more complex forms of unpacked tuples be used in the default value? I think the answer is probably yes, but it would be good to include an example.
Good idea, done.
*TypeVarTuple "subscription"*
I think I just forgot the first Foo here, my bad Foo == Foo[()] == Foo[int] == Foo[int, *tuple[Any, ...]]
*ParamSpec Defaults*
Good idea, done.
*Specifying a default of Any*
Originally I wanted to add a typing.Unknown special form as the default for default but for fear of an already broad scope creep I chose not too, but, yeah I completely agree.
*Missing type argument detection and reporting*
I feel like this is something that type checkers can chose how they want to handle themselves, this also a continuation of the previous point.