On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer
wrote:
On 7/10/17 2:38 PM, Walter Bright wrote:
On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically
determining that a function is noreturn?
It is useful anywhere dataflow analysis is useful.
FunctionThatDoesnotReturn();
a = b; // error: unreachable code
That doesn't require static introspection. The compiler can see
that, the user doesn't have to worry about it.
Note, one thing that hasn't been mentioned is how we are now
going to be able to make regular functions noreturn. This means
templates that accept aliases will now have to deal with the
possibility that those aliases are noreturn.
So if the compiler, for instance, marks the above as an error,
what happens here?
foo(alias f)()
{
f();
auto a = b;
}
if f is a noreturn function, is this instantiation an error?
Currently not. This is either a bug or the compiler's flow
analysis is not robust enough to detect this case.
int b;
auto foo(alias f)()
{
f();
auto a = b; //no unreachable code error
}
void main()
{
foo!(() => assert(0))();
}
