Proposal: Relax rules for 'pure'

Steven Schveighoffer schveiguy at yahoo.com
Wed Sep 22 10:10:36 PDT 2010


On Wed, 22 Sep 2010 12:00:16 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:

> On Wed, 22 Sep 2010 11:53:22 -0400, Don <nospam at nospam.com> wrote:
>
>> Robert Jacques wrote:
>>> On Wed, 22 Sep 2010 04:13:34 -0400, Don <nospam at nospam.com> wrote:
>>>
>>>> Don wrote:
>>>>> The docs currently state that:
>>>>
>>>>> PROPOSAL:
>>>>> Drop the first requirement. Only one requirement is necessary:
>>>>>  A pure function does not read or write any global mutable state.
>>>>>
>>>>
>>>> Wow. It seems that not one person who has responded so far has  
>>>> understood this proposal! I'll try again. Under this proposal:
>>>  Funny, your re-iteration appears to coincided to my previous  
>>> understanding. So either I've mis-understood twice, or I didn't  
>>> sufficiently demonstrate my understanding when I made my critique. :)  
>>> That said, I do think this version is much clearer and understandable.
>>>
>>>> If you see a function which has mutable parameters, but is marked as  
>>>> 'pure', you can only conclude that it doesn't use global variables.  
>>>> That's not much use on it's own. Let's call this a 'weakly-pure'  
>>>> function.
>>>>
>>>> However, if you see a function maked as 'pure', which also has only  
>>>> immutable parameters, you have the same guarantee which 'pure' gives  
>>>> us as the moment. Let's call this a 'strongly-pure' function.
>>>>
>>>> The benefit of the relaxed rule is that a strongly-pure function can  
>>>> call a weakly-pure functions, while remaining strongly-pure.
>>>> This allows very many more functions to become strongly pure.
>>>>
>>>> The point of the proposal is *not* to provide the weak guarantee. It  
>>>> is to provide the strong guarantee in more situations.
>>>  The problem from my point of view is that the programmer can not  
>>> declare that a function should be 'strongly-pure' or 'weakly-pure'.
>>
>> Yes they can. They just need to declare the parameters to be immutable.
>
> What about value types?

Value types are implicitly convertable to immutable, so they can be  
strongly-pure.  The problem I think Robert is referring to is, a person  
cannot always tell just from looking at a signature that a type is  
strongly-pure qualified or not.

For example, is this function weak or strong?

pure int foo(T t);

But the compiler will be able to tell.  I think adding a  
__traits(isStronglyPure, symbol) will be good for those rare occasions  
where you really want to ensure purity.

static assert(__traits(isStronglyPure, foo));

-Steve


More information about the Digitalmars-d mailing list