Improvement in pure functions specification

[Andrei Alexandrescu via Digitalmars-d]

On 12/21/2016 05:08 AM, Timon Gehr wrote:
> 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(;;){}
> }

I'm not a fan of claiming to be cleverer than all future programmers. 
Allowing pure void(void) functions and making the compiler call them 
compulsively was my way of saying "hm, this is clever. This is too 
blatant of an error so I can only assume you wrote this function hoping 
it will be called. No idea what you do there, but I'm going to call it."

Apparently everybody else in this thread is clever enough so I'll 
eliminate the special case.


Andrei