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.

Has anyone a better idea? Does anyone want to write a DIP for this?

Example:

DMC uses a pragma to do it:

    void ThisFunctionExits();
    #pragma noreturn(ThisFunctionExits);

GCC uses an attribute:

    void ThisFunctionExits() __attribute__ ((__noreturn__));

VC uses:

    __declspec(noreturn) void ThisFunctionExits();

On Saturday, 8 July 2017 at 10:15:39 UTC, 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.

On the contrary I think attributes are wonderful, and I have a DIP in the pipeline to address some the the problems (https://github.com/dlang/DIPs/pull/75)

>
> Has anyone a better idea? Does anyone want to write a DIP for this?
>
> Example:
>
> DMC uses a pragma to do it:
>
>     void ThisFunctionExits();
>     #pragma noreturn(ThisFunctionExits);
>
> GCC uses an attribute:
>
>     void ThisFunctionExits() __attribute__ ((__noreturn__));
>
> VC uses:
>
>     __declspec(noreturn) void ThisFunctionExits();

consider that GDC and LDC already both have that attribute courtesy of their backends (@attribute("noreturn") and @llvmAttr("noreturn") respectively).

While it may seem a good idea to unify them, if people want performance then they will use either GDC or LDC, which already have that attribute. So I would question the usefulness of such an attribute but won't go so far as to discourage anyone from trying. However it should be a compiler dependant alias in core.attribute if it is to become a thing.

On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:

> Having an @noreturn attribute will take care of that:
>
>    @noreturn void ThisFunctionExits();

Why should this be an attribute rather than a pragma? It looks to me that the goal is to pass information to the compiler, and according to the spec:

"Pragmas are a way to pass special information to the compiler and to add vendor specific extensions to D. Pragmas can be used by themselves terminated with a ‘;’, they can influence a statement, a block of statements, a declaration, or a block of declarations."

On 7/8/17 6:15 AM, Walter Bright wrote:
> Has anyone a better idea? Does anyone want to write a DIP for this?

An attribute is fine. A more PL-minded possibility is to return a specific type:

struct None
{
    @disable this();
    @disable this(this);
    @disable @property None init();
}

None ThisFunctionExits();

The compiler detects (without having anything hardwired about the particular type "None") that the type None is impossible to create and copy/move from a function, and therefore decrees the function will never return.


Andrei

On 7/8/17 7:07 AM, bachmeier wrote:
> On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
> 
>> Having an @noreturn attribute will take care of that:
>>
>>    @noreturn void ThisFunctionExits();
> 
> Why should this be an attribute rather than a pragma?

So it's part of the summary of the function. -- Andrei

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote:
> On 7/8/17 6:15 AM, Walter Bright wrote:
>> Has anyone a better idea? Does anyone want to write a DIP for this?
>
> An attribute is fine. A more PL-minded possibility is to return a specific type:
>
> struct None
> {
>     @disable this();
>     @disable this(this);
>     @disable @property None init();
> }
>
> None ThisFunctionExits();
>
> The compiler detects (without having anything hardwired about the particular type "None") that the type None is impossible to create and copy/move from a function, and therefore decrees the function will never return.
>
>
> Andrei

... since it's going to be special cased by the compiler we might as well hardwire a type called none.
Although it seems to be that the scope of no-return is extremely narrow.
Because we do have precisely builtin assert(0).

On Saturday, 8 July 2017 at 12:18:38 UTC, Andrei Alexandrescu wrote:
> On 7/8/17 7:07 AM, bachmeier wrote:
>> On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
>> 
>>> Having an @noreturn attribute will take care of that:
>>>
>>>    @noreturn void ThisFunctionExits();
>> 
>> Why should this be an attribute rather than a pragma?
>
> So it's part of the summary of the function. -- Andrei

But it's additional clutter being added for the benefit of the compiler. Additions like this make it hard for those of us showing the language to others.

On Saturday, 8 July 2017 at 10:15:39 UTC, 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.
>
> Has anyone a better idea? Does anyone want to write a DIP for this?
>
> Example:
>
> DMC uses a pragma to do it:
>
>     void ThisFunctionExits();
>     #pragma noreturn(ThisFunctionExits);
>
> GCC uses an attribute:
>
>     void ThisFunctionExits() __attribute__ ((__noreturn__));
>
> VC uses:
>
>     __declspec(noreturn) void ThisFunctionExits();

Some questions...

What kinds of control flow does this apply to?  My guess is that you consider a function to be "no-return" so long as it never returns control directly back to the caller.  The examples I can think of would be functions that prevent returning to the caller by calling exit, asserting, throwing or even just executing an infinite loop (expecting the program to exit via signal or some other means).  Is this right?

Another question I had was would the compiler provide control flow checking to make sure that the function does not return?

Also, I can imagine some optimizations that can be done with this information, would you mind sharing the optimization(s) you had in mind?

On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote:
> Why should this be an attribute rather than a pragma?

I agree. There's no reason I can think of as to why the no-return should be part of the ABI.

On 07/08/2017 08:20 AM, Stefan Koch wrote:
> ... since it's going to be special cased by the compiler we might as well hardwire a type called none.

Walter and I have repeated experience with moving compiler smarts into library artifacts. Sometimes it's arguably not the best way to go, but in the majority of cases it's been beneficial for both the language and the compiler implementation.

> Although it seems to be that the scope of no-return is extremely narrow.
> Because we do have precisely builtin assert(0).

What is the signature of a function that logs something to a file and ends in assert(0)?


Andrei