Revert "Make freed object different than null in comparison operators"

[akien-mga]

This reverts commit 150b50c.

As discussed with the GDScript team, this has some implications which aren't fully consensual yet, and which we want to revisit.

For now we revert to the 4.2 behavior for the 4.3 release, to avoid breaking user expectations.

• Reverts Make freed object different than null in comparison operators (reverted) #73896.
• Fixes Freed nodes are no longer evaluating as truthy (as in they have a value) #90513.
• Reopens Inconsistency in boolean validation of [Freed Object] #59816.

[dalexeev]

It's sad that we reintroduce the bug that if freed and if not freed are both true, but I think it's better than introducing freed != null since we haven't reached a consensus on it.

If we can find a safe way to fix the first bug without changing the second, that would be great. But until then, reverting the change looks reasonable to me.

[Macksaur]

A shame. I don't understand the consensus? are you trying to obfuscate non-owning references to Objects? imo that would be a bad choice. It should always remain possible to discern whether or not a variable has been set with a value (or not) distinct from whether or not said value is special (is_instance_valid).

Can you document more of this issue publicly?

[adamscott]

It should always remain possible to discern whether or not a variable has been set with a value (or not) distinct from whether or not said value is special (is_instance_valid).

You can always use is_same() together with null.

[Macksaur]

Ohh, does that work like an is operator? That would likely placate my future needs to avoid further changes here. However, it does feels strange that the 3.5 behaviour is not replicated properly by 4.

[DinoMC]

Here's my take on it, hopefully it can help.

I just upgraded my project from 4.2 to 4.3 beta 2 (so, a version with #73896) and it was crashing because I use "!= null" and then ".has_method('queue_free')" to check if I can free a node, but now != null returned false on previously freed objects.

Problem is, while I was trying to debug this, I set a breakpoint at the start of my function. And in the editor, while I'm paused just before the first check, I look at the stack and I see that the value of target is indeed <null>. But then if I Step Over, the check is true, and it goes to the second check.
The value does NOT show as "<Freed Object>" in the stack.

This is absolutely not my area of expertise and I'm confused by the difference between null and freed, so the following might be wrong. But to me, it seems like the change was badly implemented. I don't think it makes sense for the editor to show the value of the variable as "null", while at the same time a check of "target != null" returns true.

If this is reintroduced, I think it would need to appear correctly in the debugger.

[dalexeev]

@DinoMC #73896 has been reverted. In beta 3 the behavior will be the same as in 4.2. However, please note that is_instance_valid() is the safest and most portable option across different engine versions (including 3.x).

I look at the stack and I see that the value of target is indeed .

• See Previously freed objects shown as <null> in the debugger #92632.

See also:

• Make `null` vs `Freed Object` behavior more consistent godot-proposals#10098
• Core: Fix Freed Object booleanization #93885

[DinoMC]

Yes I know about the reverting, but it seems there's some discussions about maybe reintroducing it later in a better way so I wanted to chime in.
But my exact point was indeed already described in #92632 , didn't find that one, my bad.
In my project I have switched to is_instance_valid() and everything works well now :)