Feature

If a type is inferred as <nothing> and --strict was used, treat this as an error or warning.
Include a --disallow-nothing/--allow-nothing flag and disallow_nothing config value, or --warn-nothing/--no-warn-nothing flag and variable to control the behavior more granularly.

Pitch

From #3924, it was suggested that I open a new issue.

The following type alias produces <nothing> as the inferred return type of a function:

from typing import TypeVar, Callable
T = TypeVar('T')

F = Callable[[T], T]
def test() -> F[T]: ...
reveal_type(test) # Revealed type is 'def [T] () -> def (T`-1) -> T`-1'
reveal_type(test()) # Revealed type is 'def (<nothing>) -> <nothing>'

In #3924, this is described as a bug with the binding of T in greater detail. #3924 also includes a comment stating that <nothing> is a bottom type. I have also heard typing.Never/typing.NoReturn referred to as a bottom type, but those types are useful and desirable -- so much so that users can refer to them directly and they are part of the stdlib.

I've never wanted to produce <nothing> -- I didn't even know it existed until recently, after several years of using mypy.

My use-case is... pallets/click#2558 . A bug in a mainstream library which was trying to do everything correctly, but didn't get any warning about shipping types which produced <nothing>.
For click specifically, there are now typing tests with assert_type, so this is unlikely to recur. But if any other library were to produce <nothing> -- or, more nefariously, a type like def [T] () -> def (T`-1) -> T`-1 which can result in <nothing> -- it would be best to be able to catch it early, via the type checker.