• Andrew Pennebaker (6/6) Dec 08 2018 From my limited understanding of low-level semantics, I think
• Neia Neutuladh (15/21) Dec 08 2018 Walter wrote a DIP for this called "bottom_t". A function declared as

Andrew Pennebaker <andrew.pennebaker gmail.com> writes:

 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?

Neia Neutuladh <neia ikeran.org> writes:

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