To help LDC/GDC

Simen Kjaeraas simen.kjaras at gmail.com
Tue Apr 9 09:08:52 PDT 2013


On 2013-04-09, 17:11, Dicebot wrote:

> On Tuesday, 9 April 2013 at 14:50:58 UTC, Simen Kjærås wrote:
>> On Tue, 09 Apr 2013 16:15:40 +0200, Dicebot <m.strashun at gmail.com>  
>> wrote:
>>
>>> On Tuesday, 9 April 2013 at 14:06:31 UTC, Pelle Månsson wrote:
>>>> shouldn't be strongly pure (as it can access mutable non local state).
>>>
>>> I was under impression that pure is about verifying what function  
>>> actually does, not what it probably can.
>>
>> It's based purely on function signature, so we're dealing with possibles
>> in many cases.
>
> You got me lost here again. Definition of pure in dlang.org says: "To  
> that end, a pure function:
>
> * does not read or write any global or static mutable state
> * cannot call functions that are not pure
> * can override an impure function, but an impure function cannot  
> override a pure one
> * is covariant with an impure function
> * cannot perform I/O"
>
> It is all about behavior, not function signature. And function that  
> takes ref parameter and does not read/write it is pure by this list.

Indeed. The definition should be updated then, because it's the signature
that counts. Consider:

int[] foo(int* p) pure;

Given only this prototype, we can know that the function is weakly pure.
If a function body was required, we would know nothing more, are we to
assume it is strongly pure because no mutation is evident?

Of course we are not. In the same way, because D supports 'header' files
(files with implementation stripped out), the function signature must
convey all the necessary information to say if a function is strongly
pure or not.

-- 
Simen


More information about the Digitalmars-d mailing list