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.
