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