Improvement in pure functions specification

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Wed Dec 21 02:08:48 PST 2016


On 21.12.2016 01:58, Andrei Alexandrescu wrote:
> On 12/20/16 7:40 PM, Timon Gehr wrote:
>> On 20.12.2016 23:49, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
>>
>> Good, except:
>>
>> "$(P `pure` functions returning `void` will be always called even if it
>> is strongly `pure`. The implementation must assume the function does
>> something outside the confines of the type system and is therefore not
>> allowed to elide the call, even if it appears to have no possible
>> effect.)"
>>
>> I think this makes no sense. What is the idea behind this paragraph?
>
> A function that traces execution via a debug statement, for example. --
> Andrei

IMNSHO, that shouldn't restrict a non-debug build, and it should not be 
thought of as being outside the type system's confines. Also:

- 'void' should not be a special case: either all pure functions can be 
optimized, or none of them. (a void-returning pure function can be 
called in a non-void-returning pure function.)

- pure functions cannot be elided without considering their bodies in in 
any case, as they can terminate the program by throwing an error:

immutable(void) fail()pure nothrow @safe{
     throw new Error("boom!");
}

or cause the program to fail to terminate:

immutable(void) loop()pure nothrow @safe{
     for(;;){}
}


More information about the Digitalmars-d mailing list