How purity w/o the specific optimizations then allowed is useful ?

[Jonathan M Davis]

On Tuesday, April 16, 2024 9:07:34 AM MDT Basile B. via Digitalmars-d wrote:
> Short story for the context : someone has recently proposed the
> concept of purity for FreePascal, and only for their own dialect
> (aka _ObjFPC_). The proposition is to "check purity only when
> optimizations are enabled, because essentially the point of
> purity is only to optimize more" (think CTFE, think memoization).
>
> But [I fail to explain the
> opposite](https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/645#
> note_1863564617). How is purity a useful concept if not leading to specific
> optimizations ?
>
> And is that even the case ?
>
> Side note: I dont plan the use your answers to arguee w/ the
> author. It's more that conceptually I'm interested.

In theory, purity allows you to know that you're not dealing with side
effects outside of what can be accessed via the function arguments, because
it makes it so that you can't access global mutable state except via the
function arguments. So, in theory, it helps you to reason about the code.

In practice though, I don't think that that's actually particularly useful.
In well-written code, it's almost always the case that functions are
conceptually pure and that when they can't actually be pure, it's usually
because of reasonable stuff that doesn't actually make it harder to reason
about the code. So, personally, I'm increasingly of the opinion that it was
a mistake to add pure to D. It's very rare that it can actually be used for
optimizations (since that requires that the types involved be immutable and
that they be used in some fairly specific circumstances), and unless the
code is doing stupid stuff, it doesn't realistically help you reason about
the code even if it theoretically does.

Of course, if you have code that's constantly accessing global state, then
you're going to have issues, and pure prevents that (at least insofar as you
can't access that state except via the function arguments), but in practice,
most programs simply don't do that precisely because it makes the code
difficult to reason about and maintain.

I've often found that in projects where I've tried to use pure, I've
ultimately ended up needing to remove it because of some stray type whose
functions can't be pure because of perfectly good reasons that don't make it
harder to reason about the code. And I don't think that I've ever actually
seen any practical benefit from pure when I have been able to use it. So, if
we were creating D today - or if we were seriously looking at reworking the
attributes that we have - pure is one of those where I'd argue that it
should be on the chopping block simply because even though it's
theoretically of value, in practice, it really isn't. And since pure code
can't call impure code, it can easily balkanize code bases to have pure be a
thing.

- Jonathan M Davis