One option would be to use deprecate --disallow-untyped-defs and use --disallow-implicit-any as a superset of that option + checking that there no implicit Any types for other reasons, such the example above.

+1 to Jukka's idea. We have at least three places where an absence of type is equivalent to Any:

• Untyped definitions: def f(x, ...): ... is equivalent to def f(x: Any, ...): ...
• Normal generics x: Iterable is equivalent to x: Iterable[Any]
• Generic aliases

Maybe there others that I don't remember. It would be difficult to remember what is the option to disable each usage.

Hm, I expect that the "x: Iterable" case is very common. Would be worth doing a little experiment with that: find the code that implements this, make it raise an error instead, and see what it catches in some real-world codebases, starting with mypy. FWIW the pattern '\[AnyType\(\)\]\s*\*' seems to find many of these (I count 11).

I'm very much in favor of --disallow-implicit-any.

However, this isn't currently allowed (not sure why):

from typing import *
T = TypeVar('T')
x: List[T] # Invalid type
ListAlias = List[T]
y: ListAlias[T] # Invalid type
def f() -> None:
    x: ListAlias[T] # Invalid type

So when we need to define variables that belong to a generic container type, but without the item type being part of the type of the function call arguments, we have to rely on implicit Any like this:

from typing import *
T = TypeVar('T')
x: List
ListAlias = List[T]
y: ListAlias
def f() -> None:
    x: ListAlias

Therefore I think either the proposed --disallow-implicit-any flag should not create warnings in the second code snippet; or the first code snippet should be made legal.

or the first code snippet should be made legal.

But what you expect to be the meaning of this? Type variables are only used for generic functions, and generic types and aliases. What would be the meaning of an unbound type variable in an annotation?

I agree, x: SomeGenericContainerAlias[T] outside a function signature leaves mypy no chance to solve for T; however, it can still be used to define a generic container if someone prefers to completely eliminate reliance on implicit Any. I didn't mean to propose that, just listing it as an option.

My main point was that currently we often rely on implicit Any with a normal generic or a generic alias to specify a container type (as in my second code snippet). So --disallow-implicit-any shouldn't complain in those cases.

It feels like a special case is needed for aliases.

When C is a generic class (defined with a class statement that uses a type variable in a base class), I think we should still allow using x: C as a shorthand for x: C[Any].

But when A is a generic alias (defined with an assignment statement using a type variable on the right-hand side) the experience from #2690 and the discussion here suggest that it may be better to outright reject using x: A, instead requiring x: A[Any] if that's what is meant, or (in the parameter list of a generic function or in the body of a generic class) x: A[T].

I'm not sure I understand why we'd want to make that distinction. It seems like a good idea to keep the behavior of aliases and classes as similar as possible.

I think this is now fixed since we have --disallow-any=generics in 0.540 that also catches implicit Any in generic aliases. (IIRC it was replaced by a dedicated flag in a recent PR.)