Side Effects - are & and * part of them?

Question

Pure functions are supposed to only have contact to the outside world via parameters and return value. Like this we hope to find mistakes more quickly, limiting where we have to look.

Now my question: Calls by reference/pointer, do they count as side effects, 'tainting' our formerly pure function, or will our function still be pure?

My instinct would say that a call by value or by const reference would be the purity limit; because if we tell the function where it can get the original value and even change it, that should make things less obvious for a bug 'exterminator'.

Maybe I'd make a difference between a call by reference and a call by pointer because you explicitly pass an address to a pointer which makes it more obvious in the code.

But how is this officially handled?

Answer 1

Side effects are any change made to data outside of the function. Changing globals, reference parameters, data pointed to by parameters or globals, and even modifying class properties by a class method are side effects. The last being concidered the only side effect that should be used normally.

Answer 2

Say you got a global (integer, structure, whatever.) If it ends up with an illegal value, do you want to search for 100's of places it gets changed to put debugging in to catch the bug or one setter.

Answer 3

In my opinion using pointer arguments to return multiple values is fine. Yes we have no way to enforce that you aren't doing other side-effecty things with them, but if you are honest about it and tell everyone in the documentation then we can just pretend the function is pure.

I think the important part is what is happening inside the function and how we return things is only a formality. We can easily make a function that "returns" 2 values via pointer arguments purerer by returning a struct with 2 fields instead; but of course often that's not convenient so I'm more lenient about that sort of thing personally.

Though I can see how not everyone would agree with me there. On the other hand if we're really strict, no function is ever pure because they all write to the stack, so in a language like C we are mostly playing make-believe anyway. (C++ constexpr is probably as pure as it gets though)

Answer 4

Jay Matthews, yeah, that would be one of the cases I'm wondering about.

From within the function you change the values of two variables that could sit anywhere. On the other hand, you're at least telling this visibly with the arguments.

With a non-const cbr, you don't even have that, it will look like a cbv, but omg, stuff is 'secretly' changed!

Answer 5

from what i know, a pure function CANNOT change parameters, global or external scope vars. In practice it must use parameter only for return some value though parameter are passed by reference. The importabt is that all changes happen ONLY INSIDE his definition

P.S. Using pure functions, compilers, can apply some optimizations on they by respecting previously said rules

Answer 6

John Wells, that's strict - and also kinda consistent! Not even a class can change itself with its methods ...

Answer 7

HonFu to be pure function definitely not. But, side effects of class properties by their methods is the one place it is fully acceptable to occur for non-pure functions. The others may be okayed by the design team or Software Architect of the system. But, should be done in very controlled methods. Side effects are difficult bugs to track down so limiting them to one or two functions per data item is an extremely good design goal.

Answer 8

John Wells, so within classes, side effects are acceptable, and outside of them, there should only be one or two free functions with side effects... But what is a data item in that context? A translation unit?