Blueprint TMap 'Find' not returning values by reference
It seems as if the 'Find' node for the newly released TMap container does not return values by reference (Though I believe it is meant to). A quick way to check this is to create a TMap with any key or value type (I used Integer, Integer), and then run the following functions:
After doing so, you can check the value of key 0, and it will still be 0, despite incrementing it with the IncrementInt macro. I would imagine it is intended to be returned by reference (For obvious reasons), but if it was not intended that way, I would like to put this in as a feature request.
asked Feb 24 '17 at 01:29 PM in Bug Reports
It's intentional that Find (and array Get) returns a copy - but we would like to improve this. UE-6451 is the highest profile bug that is affected by this core behavior - and I spend a lot of time thinking about it.
The reason for this behavior is that we can't safely return a reference to data thats owned by a container type. Consider this blueprint:
My current best idea (and there may be other approaches!) is to augment the VM so that we can safely track these references and throw an exception if later statements attempt to access container memory that was freed by subsequent statements.
It's very important to us that blueprints not hard crash the UE4 process - but if this behavior is not important to you it's relatively easy to make these nodes return an unsafe reference. A related codepath is associated with the EX_ArrayGetByRef instruction identifier.
We did a little digging and the potentially stale reference above is not possible because the reference output pin results in a re-evaluation of the input expression (meaning in the example above we call NewVar1.Get(0) twice and the second time would simply fail with an out of bounds exception.
This is great news - we're hoping to provide an array Get node that returns a reference in 4.16. A Map::Find node may also make that binary release.
Edit2: by passing the reference to a function you are able to crash the blueprint runtime. We are back to square one on this front. We want blueprints to be safe, fast, and easy to use. That is a rough guide to our priorities and dominates priorities in this case.
Follow this question
Once you sign in you will be able to subscribe for any updates here