Pure functions in D

[Steven Schveighoffer]

"Bruno Medeiros" wrote
> Steven Schveighoffer wrote:
>> Another possibility is that pure functions that accept mutable parameters 
>> can only be called from other pure functions, therefore you are 
>> guaranteed that the data is not being used in any other thread.
>>
>
> I'm almost certain this is the intended behavior, with the addition that 
> you can also call that same pure function from an unpure one, only then, 
> the compiler will treat the function as being unpure. This is the gist of 
> the "partially pure"/"contextually pure" idea: a function is considered 
> pure or not dependent on the immutability of the arguments with which it's 
> called. This consideration "happens" on every call. Since the 
> optimizations to pure functions are made on the call, and not on the body 
> of the function, this is perfectly ok.
> I don't see any other behavior that isn't either broken, or more limited 
> in functionality.

One of the benefits that Walter and Andrei's original purity plan provided 
was that you could always assume that pure functions did not have to worry 
about threading issues.  I think allowing a pure function that takes mutable 
arguments to be callable from an unpure function removes that benefit.  I 
hope this isn't the case.

Of course, if shared/unshared is implemented, and pure functions are only 
allowed to be passed 'unshared' mutable data, then the benefit is still on.

I'm just unclear on what Walter is planning.  I admit I didn't read the 
whole article, I just saw that quote and thought 'hm... that looks wrong'.

>
> Also note that in the case where the given (contextually) pure "foo" 
> function is called from a pure function, the fact that foo is called from 
> a pure function only guarantees that the arguments are not changed by 
> anyone else when foo executes, but foo must still be treated as unpure. 
> Example:
>
> pure void foo(int* iptr) {
>   (*iptr)++; // side effect
> }
>
>
> pure int func() {
>   int a = 1;
>   foo(&a); // side-effect, cannot optimize this call
>   foo(&a); // side-effect, cannot optimize this call
>   return a;
> }
> // Yet func is allways pure.

I agree with you, partially pure functions can be called from pure functions 
with limited optimization.  But if you allow foo to be called from an unpure 
function you could have this problem:

int func2()
{
    static int a = 1;
    foo(&a);
}

Now, if 2 threads are calling func2, you have race conditions and threading 
issues in foo, which seems to be a major concern that W/A were trying to 
address.  And I hope they do address it, it was the one huge benefit I saw 
from pure functions.

-Steve