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