proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/18/2017 5:54 PM, Nicholas Wilson wrote:
>> There is just something fundamentally wrong with:
>>     @noreturn int foo();
> I would understand it to mean that if it were to return, foo would return an int 
> but it is undefined behaviour for foo to dynamically return.

That's the C++ behavior. I know we are all accustomed to it and hence think it 
is intuitive, but it isn't. I know I've had a hard time breaking free of this 
sort of thinking, having been so deeply immersed in C++ for so long.


>> returning a value yet not returning. It smacks of "the language designer(s) 
>> are idiots." It winds up complicating things like:
>>
>>     auto x = a ? b : foo();
>>
>> What is the type of x? @noreturn means a special case. A proper bottom type 
>> means it is not a special case.
> 
> int.

And if b is of type `T`? It doesn't make sense to have to give a type to 
something that does not return. (@noreturn functions are usually typed as 
returning `void` anyway, but that still doesn't make much sense.)

I know how noreturn attributes work - I implemented them decades ago in DMC and 
DMC++. They are supported by the DMD optimizer and back end.

But they are a hack to the type system, and I suggest an unnecessary one.

The backends for DMD, LDC and GDC would not be affected at all by the addition 
of a bottom type to the front end, and it would be trivial for the glue code to 
add the noreturn attribute for functions that return the bottom type.