Godot: setget functions are called for self assignment

[RebelliousX]

I don't know if this is the intended behavior or not (if it is, sorry, just close this issue), but this clearly should not be allowed!

Let us say,
1) I want a variable foo to have a value of 1 by default,
2) and it changes its value when user interacts in someway (let us say input).
3) After the user is done, the value of foo must have the value of 1 again.

What happens here is, the functions associated with setget are called every time the value is set to 1 when it is already 1, it should be called once (the first time) when the original value is different. This is somewhat killing the performance for me, I know I can do this:

if (new_value == old_value):
   return

But this should be done automatically.

[vnen]

I don't think it is a good idea to do this automatically. Setting a variable with the same value it already has shouldn't affect performance, this is something your setget function should handle if needed. Also, adding a value check _will_ affect performance since it's one new (conceptually unneeded) branching.

I also don't think we can just assume that the setting the same value will have no impact on the setter and thus it can be bypassed.

This looks that you have a very complicated setter if the setting of one value every time can make such a performance hit.

[RebelliousX]

Well, normally, when you only do just self assignment it wouldn't be a problem, but if you do more work than assigning new value, like what is "setget" is all about, it will hurt the performance. Especially if the value remains unchanged and self assigned every frame.

Besides, all C++ compilers (that I know of) protects you against such atrocities. (At least for basic types, overloading assigment operator you are voiding this protection) In fact, I have seen some code asserts checking for that to see if the value remains the same after self assignment for float numbers on amd cpus. That was done as sanity check for some project I forgot what it was called.

[tamkcr]

not worth breaking old code in my opinion when there is a simple work-around (I have code utilizing the setter to display a notification to user for same value assignment attempts).