www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - When should pure function modify parameters?

reply Brother Bill <brotherbill mail.com> writes:
Pure functions in Functional Programming provide the same result 
when provided the same arguments.

They are not allowed to read or write to system resources such as 
file system, console, clock, network, etc.  In addition, they may 
not read/write to module level variables.

In D, they are allowed to mutate parameters which seems to 
violate purity.  Why did D make this choice and when to best 
exploit this architectural decision.

Also, would you agree that not mutating parameters to have "true" 
purity would be preferred?
Nov 17
next sibling parent Lance Bachmeier <no spam.net> writes:
On Monday, 17 November 2025 at 14:46:06 UTC, Brother Bill wrote:

 Pure functions in Functional Programming provide the same 
 result when provided the same arguments.

 They are not allowed to read or write to system resources such 
 as file system, console, clock, network, etc.  In addition, 
 they may not read/write to module level variables.

 In D, they are allowed to mutate parameters which seems to 
 violate purity.  Why did D make this choice and when to best 
 exploit this architectural decision.

 Also, would you agree that not mutating parameters to have 
 "true" purity would be preferred?


It's been this way the entire time I've been using D (since 
2013). I've always found it weird to misuse a standard 
programming language term like this, and as a result I've never 
used it. The spec distinguishes weak and strong purity in a way 
that complexifies things without benefit, but it's not going to 
change: https://dlang.org/spec/function.html#weak-purity
Nov 17
prev sibling next sibling parent reply Serg Gini <kornburn yandex.ru> writes:
On Monday, 17 November 2025 at 14:46:06 UTC, Brother Bill wrote:

 Also, would you agree that not mutating parameters to have 
 "true" purity would be preferred?


no


 In D, they are allowed to mutate parameters which seems to 
 violate purity.  Why did D make this choice and when to best 
 exploit this architectural decision.


https://klickverbot.at/blog/2012/05/purity-in-d/
Nov 17
parent reply Lance Bachmeier <no spam.net> writes:
On Monday, 17 November 2025 at 15:20:22 UTC, Serg Gini wrote:

 On Monday, 17 November 2025 at 14:46:06 UTC, Brother Bill wrote:

 Also, would you agree that not mutating parameters to have 
 "true" purity would be preferred?


 no


 In D, they are allowed to mutate parameters which seems to 
 violate purity.  Why did D make this choice and when to best 
 exploit this architectural decision.


 https://klickverbot.at/blog/2012/05/purity-in-d/


That post answers the why but still doesn't mean the decision 
makes sense. A different name should have been chosen. The whole 
"manually make your parameters immutable" is something you can do 
with or without adding pure to the function definition. Someone 
not wanting immutable function arguments is not looking for a 
pure function. This is really bad for those of us that prefer 
functional programming, given that there's no way to mark a 
function actually pure - making it pure by the common use of the 
term is something you have to do manually on every function, and 
it's so much unnecessary boilerplate that I can't imagine someone 
doing it.
Nov 17
parent Brother Bill <brotherbill mail.com> writes:
On Monday, 17 November 2025 at 15:53:58 UTC, Lance Bachmeier 
wrote:

 This is really bad for those of us that prefer functional 
 programming, given that there's no way to mark a function 
 actually pure - making it pure by the common use of the term is 
 something you have to do manually on every function, and it's 
 so much unnecessary boilerplate that I can't imagine someone 
 doing it.


Yes, it is boilerplate.  Making a parameter 'in' doesn't take 
much typing.
I can imagine me doing it.

What I see is that in addition to the standard use of 'pure', D 
gives you some leeway if you need it.  I think I will start using 
pure for the industry wide meaning, which is that you don't 
mutate your parameters.

Using pure for ref parameters or to mutate parameters seems so 
wrong.

Having an escape hatch to do logging seems right.
Nov 17
prev sibling next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Nov 17, 2025 at 02:46:06PM +0000, Brother Bill via Digitalmars-d-learn
wrote:

 Pure functions in Functional Programming provide the same result when
 provided the same arguments.
 
 They are not allowed to read or write to system resources such as file
 system, console, clock, network, etc.  In addition, they may not
 read/write to module level variables.
 
 In D, they are allowed to mutate parameters which seems to violate
 purity.  Why did D make this choice and when to best exploit this
 architectural decision.
 
 Also, would you agree that not mutating parameters to have "true"
 purity would be preferred?


The reasoning behind D's implementation of `pure` is based on the idea
of external observability.  The motivation behind this is to make it
easier to write pure code.  "True" pure code is more difficult to write,
because you can't have mutation and mutable state, etc.. But sometimes,
the outside world (i.e., the caller) can't observe the difference
between this "dirty" code and truly pure code.  From the caller's POV,
then, it doesn't matter how the "pure" function is implemented inside;
it may be doing all sorts of "dirty", impure stuff, but if there are no
externally-observable side-effects, then it might as well have been pure
as far as the caller is concerned. Thus, it can be marked `pure` and
benefit from optimization opportunities afforded by pure code.

This is the so-called "weak purity" in D.  There's also "strong purity",
which corresponds more closely to what other languages call "pure". The
condition for strong purity is that the function cannot modify anything
through its parameters, i.e., it cannot access the external world using
a mutable reference passed to it in one of its parameters.  Strong
purity is desirable because it allows things like return value caching
optimizations.

But if we have strong purity, why bother with weak purity?  The idea is
that inside a strongly-pure function, it is OK to call a weakly pure
function.  Remember, a weakly pure function is one whose "dirty laundry"
(i.e., impure side effects) are not observable to the caller.  It *may*
modify stuff outside its scope through references passed to it.  But
this isn't a problem because a strongly-pure function does not have
access to anything in the outside world, so the worst it can do is to
pass a mutable reference to some of its own internal state to the weakly
pure function.  The overall effect is still that, as far as the caller
of the strongly-pure function is concerned, there are no observable
external side-effects, so it is indistinguishible from a "real" pure
function (the way other languages define it).

The motivation behind this relaxed purity requirement is to make it
easier to write a strongly-pure function.  You're not restricted to
calling only strongly-pure functions; you can also call weakly-pure
functions because the overall difference is not observable to the
caller.  So more code can take advantage of purity-based optimizations.

//

Having said all that, though, the actual amount of purity-based
optimizations in your typical D codebase is unfortunately rather small.
Maybe somebody somewhere is depending on this for their performance
requirements, but in practice, I'm finding that purity isn't very useful
as far as optimizations are concerned.  It's more useful for code
organization -- knowing that a function is pure makes it easier to
refactor things without breakage.  Even if it's only weakly pure, the
fact that any differences are not observable to the outside world is
still a pretty useful property one can depend on when refactoring code.

But I'd say the overall actual benefit of D's expanded definition of
purity is rather minimal, and maybe not really worth bothering with. (I
used to try to maximize pure usage; these days I don't bother anymore, I
just templatize my code and let the compiler figure out what's pure and
what's not. The optimization opportunities are limited in any case.)


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com
Nov 17
prev sibling next sibling parent Alex Bryan <abryancs gmail.com> writes:
On Monday, 17 November 2025 at 14:46:06 UTC, Brother Bill wrote:

 Pure functions in Functional Programming provide the same 
 result when provided the same arguments.

 They are not allowed to read or write to system resources such 
 as file system, console, clock, network, etc.  In addition, 
 they may not read/write to module level variables.

 In D, they are allowed to mutate parameters which seems to 
 violate purity.  Why did D make this choice and when to best 
 exploit this architectural decision.

 Also, would you agree that not mutating parameters to have 
 "true" purity would be preferred?


There's a separate mechanism for describing the immutability of 
parameters, and that's by using `const`/`immutable`/`in` for each 
parameter. The `pure` keyword for me, covers the rest of the 
purity of the function (globals). You could argue that `pure` 
should enforce `const` or `immutable` for each parameter, but I 
don't think that's a good idea as parameters are commonly used to 
return values and I think marking a function that returns values 
in one or more parameters `pure` to enforce that the function 
doesn't change any globals still has value
Nov 18
prev sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Monday, 17 November 2025 at 14:46:06 UTC, Brother Bill wrote:

 In D, they are allowed to mutate parameters which seems to 
 violate purity.  Why did D make this choice and when to best 
 exploit this architectural decision.


It only violate purity in the sense of how other language define 
it, but it makes a lot of sense to be allowed to mutate.

"pure" is a nice idea, the problem start when you want to use it 
and a lot of stuff isn't actually marked pure, such as a lot of 
core.stdc.math:

https://github.com/dlang/dmd/blob/master/druntime/src/core/stdc/math.d#L2968

Why is atan2f not pure? I have no idea.
Then constructs that could be all pure end up not being marked 
pure.
Nov 19
next sibling parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 19 November 2025 at 11:31:25 UTC, Guillaume Piolat 
wrote:

 "pure" is a nice idea, the problem start when you want to use 
 it and a lot of stuff isn't actually marked pure, such as a lot 
 of core.stdc.math:

 https://github.com/dlang/dmd/blob/master/druntime/src/core/stdc/math.d#L2968

 Why is atan2f not pure? I have no idea.


Maybe because it can set `errno` to `EDOM`, like `acos`:


 Domain error may occur if x and y are both zero.


https://cppreference.com/w/c/numeric/math/atan2.html#Error_handling
Nov 19
prev sibling parent reply user1234 <user1234 12.de> writes:
On Wednesday, 19 November 2025 at 11:31:25 UTC, Guillaume Piolat 
wrote:

 On Monday, 17 November 2025 at 14:46:06 UTC, Brother Bill wrote:

 In D, they are allowed to mutate parameters which seems to 
 violate purity.  Why did D make this choice and when to best 
 exploit this architectural decision.


 It only violate purity in the sense of how other language 
 define it, but it makes a lot of sense to be allowed to mutate.

 "pure" is a nice idea, the problem start when you want to use 
 it and a lot of stuff isn't actually marked pure, such as a lot 
 of core.stdc.math:

 https://github.com/dlang/dmd/blob/master/druntime/src/core/stdc/math.d#L2968

 Why is atan2f not pure? I have no idea.
 Then constructs that could be all pure end up not being marked 
 pure.


Isn't that because of the side effect on error ?

(https://www.felixcloutier.com/x86/fpatan#fpu-flags-affected)
Nov 19
parent Guillaume Piolat <first.nam_e gmail.com> writes:
On Wednesday, 19 November 2025 at 13:05:52 UTC, user1234 wrote:

 Isn't that because of the side effect on error ?

 (https://www.felixcloutier.com/x86/fpatan#fpu-flags-affected)


Probably because it sets errno, just like malloc and free.
And what is the popularity of pureMalloc / pureFree and would-be 
pureAtan2f ? Not very popular.
Nov 19