From my limited understanding of low-level semantics, I think that exit() doesn't allow execution to proceed to the next statement. Right?

Given that, I am curious if we could treat exit() as a valid last statement in switch cases, along with break, continue, and so on. What do you think?

On Sun, 09 Dec 2018 04:51:43 +0000, Andrew Pennebaker wrote:
> From my limited understanding of low-level semantics, I think that exit() doesn't allow execution to proceed to the next statement. Right?
> 
> Given that, I am curious if we could treat exit() as a valid last statement in switch cases, along with break, continue, and so on. What do you think?

Walter wrote a DIP for this called "bottom_t". A function declared as returning bottom_t does not return. This would include exit(2), OS- specific equivalents to it, and wrappers around functions like that.

The response was that a way to mark a function as not returning was useful, adding it to the type system was not. For compatibility, functions like this might need to be declared with a real return type. Sometimes this might need to appear in, for instance, a C++ mangled name. Or you might have an array of functions, one of which might not return; you'd like to be able to put that function in the array while specifying at its declaration point that it doesn't return.

Calling a never-returning function would work the same as throwing an exception, asserting false, etc; it'd be a valid thing to end a case block with.

https://github.com/dlang/DIPs/pull/117/files