Proposal: Relax rules for 'pure'

Steven Schveighoffer schveiguy at yahoo.com
Wed Sep 22 14:19:42 PDT 2010


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

I just thought of something -- we may be defining the common case.  For  
example, D breaks from the default of shared globals in C because most of  
the time, variables *aren't* shared.  When I first heard of shared, I  
thought surely Walter was losing his mind.  Why would shared not be the  
default, clearly as it's done in C!  But after having used the language, I  
see that it would have been a huge issue if I had to mark everything as  
unshared.

If we can define weakly pure functions this way, they most likely will be  
way more common than unpure functions.  I know I avoid accessing global  
variables in most of my functions.  Think about a range, almost all the  
methods in a range can be weakly pure.  So that means you need to mark  
every function as pure.

Would it not be less tedious to mark unpure functions instead of pure  
functions?  Or am I just going too far with this?

OR, maybe we could say, mark strongly pure functions as pure, mark  
functions that access global data as something else (global?) and weakly  
pure functions just aren't marked.

-Steve


More information about the Digitalmars-d mailing list