pure functions cannot be removed, actually: pure vs. total

Timon Gehr timon.gehr at gmx.ch
Mon Jun 11 18:23:18 UTC 2018


On 11.06.2018 20:15, Steven Schveighoffer wrote:
> On 6/11/18 10:43 AM, Timon Gehr wrote:
>> On 11.06.2018 16:39, Timon Gehr wrote:
>>>
>>> FeepingCreature's example does not really qualify as a do-nothing 
>>> loop, because the loop produces a value that you (presumably) later 
>>> access.
>>
>> Hm, ok. The problem is actually there, but it is not that the 'find' 
>> call will get removed, it is that the loop within find's 
>> implementation will be seen as doing nothing and producing nothing 
>> after inlining, breaking find's postcondition.
> 
> Actually, one thing that can be determined statically is that it will 
> never return. Essentially, this particular find function (with predicate 
> inlining) will fold to:
> 
> while(true) {}
> 
> Since the final return outside the loop is obviously never reached, and 
> the return inside the loop cannot be reached.
> 
> So I would assume this would properly be translated to an infinite loop.
> 
> I was not expecting that the compiler might eliminate infinite loops 
> that it can prove are infinite loops, more like it should eliminate 
> calls that trivially can be proven to do nothing based on the signature 
> of the function.
> 
> -Steve

Well, if the language definition is reasonable, then if calls to `void 
foo()pure @nothrow { while(true){} }` can be elided, so can the 
`while(true){}` loop itself.


More information about the Digitalmars-d mailing list