20673, "vasslitvinov", "how to handle unreachable code?", "2022-09-09T22:13:06Z"
This is a follow up on #20497 and #20658 to finalize the desired semantics. We would like to resolve the following design questions:
What code should be considered "unreachable" ?
after return, throw
after a call to halt() or exit()
after a call to what other halt-like functions?
after an if-statement with both branches containing unreachable code
after an if-statement that folded away one branch and the other branch contains unreachable code
after a block-statement containing unreachable code
after a select-statement, analogously to an if-statement
what else?
How should unreachable code be handled?
it should be parse-able
ignored otherwise; see also warning/error below
or, it is implementation-dependent whether it is ignored or compiled normally?
What kinds of statements should still be handled normally even though they are unreachable?
function and type declarations
what else?
Should we allow an unreachable return statement to affect the implicitly-inferred return type of the enclosing function?
#20497 allows this
the proposal is to disallow this; instead the return type should be declared explicitly
The disadvantage is that calculating a type in the function header may be difficult, compared to providing it in the function body where the user can refer to other things that the function calculates internally.
This proposal requires that a non-void explicit return type should be legal when the end of the function body is unreachable. Currently the implementation satisfies this requirement. Todo: reflect this in the documentation if not already.
Should we issue a warning that the compiler is ignoring some code that is unreachable?
Or an error?
Definitely not when the unreachable code became unreachable because of parameter folding, like if xyz then return 5; return "hi";