proposed @noreturn attribute

[Meta via Digitalmars-d]

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))();
}