allow `...` in place of generic parameters

from https://github.com/python/mypy/issues/11389

Feature

in kotlin, you can omit a generic from a type annotation when you don't care what its value is:

class Foo<T: Number>

fun foo(value: Foo<*>) {}

more info:

• https://kotlinlang.org/docs/generics.html#star-projections
• https://typealias.com/guides/star-projections-and-how-they-work/

Pitch

• it's especially useful for types that have multiple bounded generics

  i think this could be accomplished by simply allowing ... to be used in place of the generics

  Thing1 = TypeVar("Thing1", bound=Base1, covariant=True)
  Thing2 = TypeVar("Thing2", bound=Base2, covariant=True)
  Thing3 = TypeVar("Thing3", bound=Base3, covariant=True)
  
  
  class ThingWithLotsOfGenerics(Generic[Thing1, Thing2, Thing3]):
      ...
  
  
  def foo(value: ThingWithLotsOfGenerics[..., ..., ...]) -> None:
      ...
  

• Another usage is to ignore variance issues when you don't care about accessing the values.

  @dataclass
  class Box(Generic[T]):
      t: T
  
  def foo(b: Box[...]):
      print(b)
  def bar(b: Box[object]):
      print(b)
  
  b = Box(1)
  foo(b)  # no error
  bar(b)  # error, Box[int] incompatible with Box[object]
  

Alternatives

Use Any

Any removes all type safety so is not a good solution

T = TypeVar("T")

class Foo(Generic[T]):
    a: T

def foo(f: Foo[Any]):
    f.a = "AMONGUS😳"

f = Foo[int]()
foo(f)

Use object/Never

This doesn't work if your TypeVar is bound, you have to specify the bound, which is non-optimal for many reasons.

class Foo: ...

T = TypeVar("T", bound=Foo, covariant=True)


class Bar(Generic[T]):
    ...


# error: Type argument "object" of "Bar" must be a subtype of "Foo"  [type-var]
def foo(value: Bar[object]) -> None:
    ...

(also being tracked in KotlinIsland/basedmypy#30 and https://github.com/DetachHead/basedpyright/issues/18)

Start by reading the linked mypy issue and the Kotlin star-projection documentation. Compare the proposed ... syntax with the Any, object, and Never alternatives, then determine the typing semantics and implementation scope. Done requires an agreed specification and corresponding support across the relevant type-checking tools.