Proposal: Relax rules for 'pure'

[Lutger]

Don wrote:

> The docs currently state that:
> ---
> Pure functions are functions that produce the same result for the same
> arguments. To that end, a pure function:
> 
>      * has parameters that are all immutable or are implicitly
> convertible to immutable
>      * does not read or write any global mutable state
> ---
> 
> This is extremely restrictive, and not currently enforced.
> Two specific limitations:
> - a 'pure' member function doesn't really make sense (could only be
> called on an immutable class)
> - a pure function cannot have 'out' parameters.

Would it be possible to make an exception for out parameters? After all they can 
be considered part of the output, and as input are always initialized to the 
same value. The result of a function can be defined as the tuple of its return 
value and all out parameters.
 
> In a discussion on D.learn, Steven Schveighoffer noted that it's only
> shared variables which make things complicated.
> The limitations exist because 'pure' is used to mean both 'no hidden
> state' AND 'cachable'. But 'cachable' is really only an implementation
> detail.
> 
> PROPOSAL:
> Drop the first requirement. Only one requirement is necessary:
> 
> A pure function does not read or write any global mutable state.
> 
> If a pure function has parameters that are all immutable or are
> implicitly convertible to immutable, then the compiler is permitted to
> cache the results.

If pure functions are allowed to mutate their input parameters, do we not lose 
referential transparency?

a = pureFun(input);
b = pureFun(input);

assert( a == b );

Or am I misunderstanding your proposal?