December 09, 2018 Treat exit() as a valid last statement in a switch case | ||||
---|---|---|---|---|
| ||||
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? |
December 09, 2018 Re: Treat exit() as a valid last statement in a switch case | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Pennebaker | 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 |
Copyright © 1999-2021 by the D Language Foundation