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? That's
going to get messy. It's not a problem today, because you can't alias
`assert`, and the compiler doesn't care about other functions that don't
return (even if they are completely available).
I learned the hard way with inout not to proactively make obvious errors
errors. For instance, you can't return inout if you don't have any inout
parameters. It makes complete logical sense when you think about it,
just use const. This leads to the (inout int = 0) crap we see everywhere
in phobos.
-Steve
