Testing suggests that if my_node: and is_instance_valid(my_node) always return the same result. Reddit and a Github discussion say that a boolean check on an object returns false if the object is either null or freed_object. But then I’m not sure why both the boolean check and the is_instance_valid() check are available. I asked an LLM; it insists that I should use is_instance_valid() because it’s best practices, but it can’t provide a situation where the result would actually be different. Instead it derails into telling me not to do “null” checks—which is not what I’m asking, since I understand that a freed object does not always return null.
Basically, since I find if my_node: easier to write and read, I’m wondering if I really need to use is_instance_valid(), best practice or not.
``ìf node```will test whether node is null or not. But there might be situation where the varaible still points to some adress, but the object is already freed and is therefore not usable for you anymore. This can and has happened to me.
So if you want to check whether the variable is still “useful”, I’d suggest to use ``ìs_instance_valid```.
bool is_instance_valid(instance: Variant)
Returns true if instance is a valid Object (e.g. has not been deleted from memory).
I might be wrong, but it seems to me that they are two different things.
“if my_node:” says nothing about whether the object “has been deleted from memory”.
And “is_instance_valid” does not know whether that object is still referenced somewhere.
If you don’t care about whether the object is deleted from memory, I don’t see why you should not use “if my_node:”. I use it all the time.
In my opinion you should remove all the references to a node when freeing it (set them to null or remove from array/dictionary), and if you do that, I believe you can always use if my_node
There are cases in which my_node may contain a value that truthy (i.e. evaluates to true when put in if statement) but it’s still not a valid instance. This can happen if variable is not typed.
For example with var a = 10, if a will evaluate to true but instance validity check on it will return false.
However if my_node is declared as an object type, those two are pretty much interchangeable in if statements.
Note: In a boolean context, an Object will evaluate to false if
it is equal to null or it has been freed. Otherwise, an Object will
always evaluate to true. See also @GlobalScope.is_instance_valid().
My thinking is: if an object evaluates to false if it is equal to null or it has been freed then how is is_instance_valid(my_node) any different or better than if my_node:? Why have both?
The best answer I have is that, based on this and this Github discussions, it’s vaguely maybe theoretically possible that the engine designers will decide, at some point, to change it so that an object that is not null but is freed will resolve to true in if my_node:.
But as far as I can tell right now, if my_node: and is_instance_valid(my_node) currently always have the same result. I posted to see if anyone knows of an edge case where that’s not correct.
``ìf node```will test whether node is null or not. But there might be situation where the varaible still points to some adress, but the object is already freed and is therefore not usable for you anymore. This can and has happened to me.
if node: tests both whether the node is null and whether the node is freed, per the docs for Object I quoted above. It’s not just a null check, it’s not the same as if node == null.
As I said, is_instance_valid() tests if any Variant is a valid instance. You may pass anything there, not only valid/freed object references.
When compiler converts an object reference to a boolean value in an if statement, it may well be calling is_instance_valid() under the hood if the given Variant is an object reference. So you can consider if node a shorthand for if is_instance_valid()
I got it now. It’s an additional check to make sure I didn’t do something boneheaded resulting in me somehow passing something that I think will definitely be an object but isn’t. Which is an error I ran into plenty of times using a type unsafe programming language in the past.
My hubris has been my undoing in the past, so even though I always assign types, I’ll use the more awkward is_instance_valid() check to be safe.
I personally always use the shorthand, however using is_instance_valid() can increase readability of your code as it makes it clear that you expect the thing you’re testing to be an object that may or may not have been freed.
