proposed @noreturn attribute

Rainer Schuetze via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 11 00:41:58 PDT 2017



On 08.07.2017 12:15, Walter Bright wrote:
> C compilers (and by extension C++ compilers) usually have an extension 
> which allows a function to be marked as one that never returns. The 
> point of this is it enables improved data flow analysis and better code 
> being generated.
> 
> Noreturn functions crop up in things like assert's and enforce's. DMD 
> internally hardcodes a few functions it knows about that are noreturn, 
> and the DMD optimizer and codegen take advantage of it.
> 
> But when people write their own assert's and enforce's, this falls 
> apart. While the programs will still work, they won't be as efficient as 
> they could be.
> 
> Having an @noreturn attribute will take care of that:
> 
>     @noreturn void ThisFunctionExits();
> 
> Yes, it's another builtin attribute and attributes are arguably a 
> failure in language design.

I don't like the inflation of attributes, too, but encoding it into the 
return type seems too clever, especially when having to explain it again 
and again to people without functional language background (like me).

A few questions inspired from discussion in 
https://github.com/dlang/druntime/pull/1839:

- Does @noreturn need to be inferred for templates?

     void msgAssert(bool cond)(string msg)
     {
         debug writeln(msg);
         assert(cond);
     }

- The template function above is (strongly) pure, how does @noreturn 
interact with that? Will @noreturn ensure it is not elided?

- If it does, how does this propagate to a function calling it, e.g.

    void c_assert(bool cond, string msg) pure
    {
        if (!cond)
            msgAssert!false(msg);
    }

A call to c_assert can be elided according to the pure rules. Any chance 
that this can be avoided with the help of @noreturn?


More information about the Digitalmars-d mailing list