proposed @noreturn attribute

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote:
> 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();

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.

> 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. @noreturn need not pollute the type, given the use cases for 
@noreturn. Namely to document that the function does not 
dynamically return and aid the compiler in optimisation (are 
there any other uses?). `assert(0);` is already accepted in the 
front end as an acceptable return "value" for any type e.g. in

Bar foo(int x)
{
     foreach (e; data[])
          if (e.x == x)
               return e;
     assert(0);
}

> The language semantics and compiler internals should be simpler 
> and cleaner by using accepted type theory.

Not for LDC or GDC. They already have the ability to signal to 
their backends that a function does not dynamically return.

as I have posted before, one can do (in core.attribute),

enum __noreturn;

version(LDC)
{
     import ldc.attributes : llvmAttr;
     alias noreturn = AliasSeq!(llvmAttr("noreturn"),__noreturn);
}
else version(GNU)
{
     import gcc.attribute : llvmAttr;
     alias noreturn = AliasSeq!(attribute("noreturn"),__noreturn);
}
else // DMD
{
     alias noreturn = __noreturn;
}

for a complete implementation for LDC and GDC, and DMD can do 
whatever it needs to with the presence of __noreturn, including 
fronted semantic analysis.