A `NoReturn` type is needed

[o11c]

In order to perform branch analysis, it is necessary to know which calls will never return normally. Examples are sys.exit (which always returns via exception) and os.exit (which never returns).

NoReturn should drop out of Union and dominate Intersection.

To manually mark a branch as dead, use cast(NoReturn, expression) in an expression context, or raise in statement context.

This can also be used as the return type of __init__ or __new__ or the metaclass's __call__ to indicate types that can't be normally instantiated.

[JukkaL]

A simpler approach would be to just teach tools about common things that don't return such as exit, and require some form of annotation elsewhere, such as a raise statement:

def f() -> int:
    if foo:
       return 1
    else:
        function_that_does_not_return()
        raise NotReachable

This has the benefit of making things more explicit for the reader and getting a runtime error if the expectation doesn't hold. Functions that don't return are special beasts anyway, and maybe explicit is better than implicit in this case.

[gvanrossum]

FWIW, I've never liked functions that don't return. Other tools are also
confused by them (e.g. the auto-dedent functionality in editors).

On Thu, Oct 29, 2015 at 9:49 PM, Jukka Lehtosalo notifications@github.com
wrote:

A simpler approach would be to just teach tools about common things that
don't return such as exit, and require some form of annotation elsewhere,
such as a raise statement:

def f() -> int:
if foo:
return 1
else:
function_that_does_not_return()
raise NotReachable

This has the benefit of making things more explicit for the reader and
getting a runtime error if the expectation doesn't hold. Functions that
don't return are special beasts anyway, and maybe explicit is better than
implicit in this case.

—
Reply to this email directly or view it on GitHub
#165 (comment).

--Guido van Rossum (python.org/~guido)

[o11c]

Requiring raise works in simple cases, but consider:

@overload
def foo(arg: int) -> int: ...
@overload
def foo(arg: str) -> NoReturn: ...
# other overloads with different return types

def bar(arg: Union[int, str]):
    x = foo(arg) # x has type `int`

just teach tools about common things that don't return such as exit,

Needing to special-case like that is a sign of bad design.

And auto-dedent is never going to be perfect anyway, it's more important to have completeness.

[elazarg]

(I apologize for repeating things I've said on related discussions):
NoReturn is simply the empty Union (though in mypy there's a dedicated class UninhabitedType). It might need an alias for readability, but these concepts have exactly the same meaning, AFAIK.

[gvanrossum]

We're moving ahead with NoReturn as a mypy extension first, see python/mypy#2637. Once we're confident that it works we'll add it to typing.py -- this issue will be left open as a reminder for that.

Regardless of whether it's the same as Union[()], we should not spell it that way -- it's ugly, it's hard to search for, and it currently doesn't work anyways, so it would be subject to the same release-mechanical problems as NoReturn (probably slightly worse because you'd have to remember to write from mypy_extensions import Union).

[elazarg]

I don't think I have suggested to spell it Union[()], from the point of view of the user; I agree it's ugly. I just want to treat it as equivalent, regardless of syntactic difficulties, instead of having a new concept floating around in mypy (we have UninhabitedType already). So if it does not worth a new syntax, it can be aliased right inside mypy.

Unless there is a difference, in which case it's interesting to know about it (for example, if None is an element of the empty union, then they are not equivalent)

[gvanrossum]

@ddfisher ^^ Here's some feedback from @elazarg for the implementation of NoReturn for you.

[ddfisher]

None may or may not be a member of the empty Union in non-strict-Optional mypy -- I don't think it's currently clear either way (but this shouldn't be a big deal, because typing doesn't allow you to specify empty Unions).

I think there's a decent argument to be made that NoReturn should be the same as UninhabitedType. From a type-theoretical perspective, it certainly makes sense, but I'm not sure we actually want them to behave identically. Let me cogitate on this a bit.

[markshannon]

What is the point of this?
To specify that a function never returns (like sys.exit in a stub file) or to verify that a function never returns?

The former can be easily done with

def exit(code=1):
     raise SystemExit(1)

I don't really see the point of the latter.

[gvanrossum]

It is needed to specify that a function never returns, so that local code paths involving such a call can be analyzed correctly.

We considered the raise syntax you proposed, but (a) it could only work in stubs, and (b) this is already used in typeshed to indicate that a function may raise a given exception (presumably as a pytype extension).

[markshannon]

That's unfortunate.

Why not distinguish between "may raise" and "will raise"?

def may_raise(...):
    if random():
        raise ...

def will_raise():
     raise ...

I do worry that a lot of useful information that could be in the stub files is being thrown away.

[elazarg]

I think "no return" and "will raise" are different guarantees, and

def foo() -> NoReturn:
    do_some_stuff()

is very clear, and we can also verify that do_some_stuff() does not return.

What is the problem with this addition?