proposed @noreturn attribute

[Steven Schveighoffer via Digitalmars-d]

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