Proposal: Relax rules for 'pure'

Robert Jacques sandford at jhu.edu
Wed Sep 22 18:48:19 PDT 2010


On Wed, 22 Sep 2010 13:10:36 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> 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.

No their not. Remember, arrays and other structs are value types in the  
type system. Logically, they may be reference types, but as far as their  
type signature goes, they are value types.

> 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.

And that you can not manually specify one or the other.

> 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

This would work, but it wouldn't be self-documenting, etc.


More information about the Digitalmars-d mailing list