proposed @noreturn attribute

[Steven Schveighoffer via Digitalmars-d]

On 7/10/17 3:05 PM, Meta wrote:
> 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.

I think the implication from Walter is that f would be treated just like 
a direct call to assert(0) (i.e. it doesn't return).

So where code like this produces an "unreachable statement" error:

void foo()
{
    assert(0);
    auto a = b;
}

with dmd -w, code like the above will potentially produce an unreachable 
code error if f is a noreturn (the compiler can now do dataflow analysis 
and determine it's unreachable).

This means that you get errors for some instantiations. Which ironically 
means you'd need to do something like this:

void foo(alias f)()
{
    f();
    static if(!isNoreturn!f)
    {
        auto a = 5;
        ...// etc.
    }
}

Today, it's not a big issue. We can't alias `assert` function directly, 
so it's obvious where it's an assert or not (because you have to spell 
it out!).

We have similar problems today with generic code causing unreachability 
errors. See for instance https://issues.dlang.org/show_bug.cgi?id=14835

-Steve