purity question

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, May 30, 2017 16:54:13 ag0aep6g via Digitalmars-d-learn wrote:
> On 05/30/2017 11:12 AM, Rene Zwanenburg wrote:
> > If malloc were marked as pure, wouldn't that mean it must return the
> > same pointer every time you call it with the same size?
>
> D's `pure` mostly means: "does not access mutable state, and does not do
> input/output".
>
> There is never a requirement that a function must return the same value
> for the same input. But a compiler is allowed to memoize the result of a
> `pure` function when it has no mutable indirections in its parameter and
> return types. Such a function is "strongly pure".
>
> When there are mutable indirections, the function is "weakly pure".
> Weakly pure functions are not assumed to be memoizable, but "weakly
> pure" still has meaning:
>
> * Can call weakly pure functions from strongly pure ones.
>
> * When a weakly pure function has mutable indirections in the return
> type but not in the parameters (like malloc), then it must be returning
> freshly allocated memory. That means, the result cannot be referenced
> from anywhere else. So it can be converted to const/immutable/shared
> implicitly. The spec calls that a "pure factory function".
>
> Repeating Biotronic's links, the spec and David Nadlinger's article are
> the go-to resources for D's take on purity:
>
> https://dlang.org/spec/function.html#pure-functions
> http://klickverbot.at/blog/2012/05/purity-in-d/

Yeah, basically, D's pure was originally what is now sometimes called
"strongly pure," which is quite close to functionally pure in that the same
input results in the same output (it still allows alocating memory and
returning it though, so you can have equal but different objects if the same
function is called multiple times with the same arguments in different
contexts where the compiler doesn't memoize it). However, pure was so
restrictive as to be borderline useless, because it could only pass types
that were immutable or implicitly convertible to immutable. So, it was
expanded to include any function which could not access global, mutable
state, because such functions can be called from a "strongly" pure function
without violating the strongly pure function's guarantees - and thus
"weakly" pure functions were born, making it so that D's pure is really more
like @noglobal than functionally pure. It's a critical building block in
functional purity, and strongly pure functions still get all of the benefits
that they got before (and now they can actually be useful, because they can
call many more functions), but _most_ pure functions are weakly pure and
thus don't get the full benefits of functional purity - and that's why some
folks like Ketmar tend to get annoyed with D's pure. But the way it is is
actually quite useful even if it's initially confusing. And even when there
are no strongly pure functions in your program, knowing that a function
cannot access global variables except through its arguments means a lot in
and of itself.

- Jonathan M Davis