proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote:
> But the point is that so much time and effort is being spent on
> discussing and designing a feature that you have admitted yourself to be
> "rarely used". As a disinterested bystander I find it somewhat amusing
> (and sad) to see so much over-engineering of an overly-complex system
> involving a new basic type in the language, which in turn entails all
> sorts of corner cases in how it will interact with existing types and
> constructs, not to mention the implementation complexities that will be
> involved to pull it off -- all for what?  Just to be able to say
> "function F doesn't return".  Seems like disproportionate effort for
> only marginal returns (har har).

The issue here (for me) is to have a type system that matches type systems used 
in type theory. D already has strong abilities to do type calculus. Instead of 
inventing our own whackadoodle scheme, one hack at a time, why not match 
existing type calculus? Then, attempts to do type calculus in D will work as 
worked out by type theory.

Or, we could go with the C++ approach which historically is to add an ad-hoc 
solution for an existing problem, and then another ad-hoc solution for the 
whacky effects that turned out to have, rinse, repeat. (Look at all the 
different ways to do type deduction, a horrifying consequence. Or function 
overloading, which started with complex special cases, then changed to partial 
ordering for special cases.)

There is just something fundamentally wrong with:

     @noreturn int foo();

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.


I recall that Rust initially did @noreturn as a special case, and later replaced 
that with a bottom type and integrated it into the type system. I understand 
that this had a positive ripple effect, such as reducing special cases in user 
generic code.

Noreturn functions are just a happy fallout of doing this correctly in the first 
place. The language semantics and compiler internals should be simpler and 
cleaner by using accepted type theory.