Purity has its origin in functional programming languages. It is a promise: Given a certain input the function will return always the same output. (No side effects)
There are some comments in the UE code that indicate that Epic actually wanted to implement it that way.
// @todo: the presence of const and one or more outputs does not guarantee that there are
// no side effects. On GCC and clang we could use __attribure__((pure)) or __attribute__((const))
// or we could just rely on the use marking things BlueprintPure. Either way, checking the C++
// const identifier to determine purity is not desirable. We should remove the following logic:
Why is that important?
If implemented correctly you can optimize. Say a pure function is called every thread with the same input. Since we know that the output will always be the same we can cache the output and save performance.
We could multithread the function calls without worries - probably not worth it for now but may be interesting in the future.
I love blueprint because they help you visualize the flow of state. Say you have the following code in C++.
FVector Pos = GetActorLocation();
SetActorLocation(Pos + Offset);
Reading the code we don’t know if it is important that SetActorLocation is called before DoSomethingWithTheActor.
The second variant implies that DoSomething does not care about the changed actor location and may be put before SetActorLocation
But ‘pure’ functions destroy the picture
There is no visual hint that the GetActorLocation node result may change during the execution path. Now imagine this example with more nodes or the SetActorLocation call inside a nested function call.
You actually need to add a local variable or wrap the GetActorLocation inside another function to fix this
or this one: I hate the make array node
Whenever you declare a const function as pure you introduce the possibility for a (semantic) bug. They may be useful when you work with data that may not change during gameplay. e.g. the game mode or player controller. But please don’t declare const functions as pure if you expect their dependent state to change (positions, variables etc.)
Now this is my opinion having a functional programming background. I am very interested in yours. Did you stumble upon the same bugs as I described? Can you show me examples where it results in a clear interface?