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
