I make an error in my previous post, in functional languages pure functions are one that compute their result only using the parameters specified, thus they does not depend on state on nay object.
In Unreal Engine Pure - is some form of const function, which is expected to by fast computed, and does not change state of it’s object.
But impure function can change the state of the object, so value of pure function must be reevaluated after Impure Functions calls.
That is like getting actor position before and after Actor Move node. You definitely should have different positions returned.
I also two hands for short-circuiting. have a solution, but I am not sure if I want to use such approach.
Pure does not mean it won’t change the state or value of anything, although it generally implies that it won’t change the state of anything you care about (see getting random numbers from streams for example).
Const means it won’t change anything (this is compiler enforced).
Its generally a good idea to mark all your pure functions const, and all your const functions pure if possible.
The confusion comes mostly from the meaning of pure in functional programming. BP pure is a long way from being the same.
As has been said, it is intended to imply no observable state change on the object in question, though I agree with @, the random stream nodes are somewhat borderline in this respect.
In practice, ‘pure’ in BP just means that the node doesn’t have execution pins and is thus subject to different evaluation rules. Specifically, it gets evaluated once for every pin into which its outputs are plugged. As such, as @Yata points out pure nodes should really be low overhead, since they can be evaluated many more times than most people might expect. Multi-output pure nodes are especially dangerous in this way.
So yeah, I don’t really like it and it’s far from efficient if you’re not very careful about how you use them. But I also figure it has zero of ever being changed since doing so would fundamentally break pretty much every blueprint ever. The feature request at the end of this thread seems like the best compromise, but that was 2 years ago…
As I said originally: Yes, it’s fine the way it is, we can all live with it, especially if the execution semantics are clearly documented somewhere a programmer will easily find it when looking for it.
That being said, renaming “pure” to something else would help. “implicit” would be my favorite. Meaning, execution time is implicitly determined, rather than explicitly. (“implicit” of course has a different meaning in Scala, but let’s not get too excited about that!)
Separately, I still think short circuiting is a good thing, if we could have it. It is unlikely to break existing code, and it may give someone somewhere a bit of performance help.
Exactly. In the end, C++ and most languages offer &,| for an eager evaluation and &&,|| for short-circuit evaluation. Something equivalent for BP would be nice.
If migration is not an issue and we know of the changes then I think it could be worth it, Blueprint will never go anywhere as long as we are all scared of breaking legacy support. Obviously its not an ideal situation but expressions evaluation should be optimal and not causing unwanted strain on a system. These nodes dont completely serve their purpose because of this reliance on execution flow to get around the problem.
As a person who only uses Blueprint I think its unacceptable to leave it as it is, that if this were any other language we wouldnt be so willing to just leave it as it is. I support any changes to Blueprint needed to make it better and if there are issues with migrating code that should also be discussed indepth and how we can find solutions that work in that regard. As it stands if people dont like the changes they can simply stay on older versions of the engine!
+1 million for this. I use Select nodes a lot, and without short circuiting you can’t bool select vars on an object off of an IsValid targeting that object.
+1, would love this for boolean ops and for select nodes… select nodes are a great way to reduce graph clutter - while making your logic more expensive. It seems counterintuitive that what looks more elegant is actually less optimal.
+1, I really don’t understand why this is even a debate.
Short circuiting has advantages both in performance and readability and has no disadvantages, as evident by its existence in virtually all modern languages.
The only consideration is if it’s worth the development resources, and it is.
I think that what you guys are looking for actually exists in our database as a bug. Here’s the link to the issue on our public tracker, in case you’re interested.
Pure in Blueprints does not mean the same as pure/referentially transparent in (functional) programming. In blueprints it simply means that the node doesn’t have the Exec pin, the one where the white execution line would plug into.
As a side note, I dislike the “pure” term in Blueprints just because of this reason, it’s confusing and contradicts established terms in general programming.
The idea is however to have pure BP functions be ACTUALLY pure, but the fact is that there is nothing enforcing this in BP, it’s merely suggested by the name.
