Improvement in pure functions specification

[Jonathan M Davis via Digitalmars-d]

On Friday, December 23, 2016 14:12:54 Observer via Digitalmars-d wrote:
> On Friday, 23 December 2016 at 11:11:09 UTC, Jonathan M Davis
>
> wrote:
> > Conceptually, it makes no sense to be doing any of that sort of
> > thing in a strongly pure function, because at that point, we're
> > really talking functional purity.
>
> I understand your points.  I had been thinking about purity purely
> from the standpoint of external mutation, since that's what the
> TDPL
> discussion emphasizes, and neglected to consider possible compiler
> optimizations (hoisting calls out of loops, for instance).  That
> sort of thing would definitely mess with all of the examples I had
> proposed.

Optimization really only comes into play when the function is "strongly"
pure so that the compiler can guarantee that the arguments aren't mutated
and thus can guarantee that the function will always give the same result
for the same arguments, but it was originally one of the primary goals of
pure. Once pure was expanded to include "weakly" pure functions that
accepted mutable arguments but just didn't access mutable global state, then
the benefits of pure expanded considerably without really adding to the
optimization opportunities beyond the fact that without relaxing the purity
rules, pure functions were almost useless, because having to have all of the
parameters be immutable or implicitly convertible to immutable was just too
restrictive to be useful in most cases.

But since the whole reason that pure was relaxed was to make it so that more
functions could be "strongly" pure, we really don't want to degrade pure so
far that we lose out on the original benefits that pure was supposed to
provide, much as the fact that a pure function can't access mutable, global
state except via its arguments is actually a big benefit in its own right
even without the optimizations entering into the mix.

- Jonathan M Davis