@peterdrake For the same reasons, it does not support the "is null" / "is not null" syntax in newer versions of C#.
@bernardo_olafson @peterdrake To add to this, if I recall correctly, they'll also "== null" not only when they're actually destroyed, but also when they're queued for destruction (i.e. when you call Destroy() rather than DestroyImmediate()).
But the benefit of all this nonsense is that we can use "== null" as a check of destruction, rather than having to clean up all of our own references to any object we destroy!
@LouisIngenthron @bernardo_olafson My beef (well, one of my beeves) is that this business isn't documented anywhere that is (to me) obvious. It's just scattered around various conflicting and unclear StackOverflow posts, with endless offramps to things like "is {}".
Unity is like Columbo, always turning around at the end and saying, "Oh, and one more thing..."
@peterdrake @LouisIngenthron Unity documentation is quite poor when it comes to more in depth technical info, indeed. you need to collect info from several sources. yes, this can suck...
@peterdrake @LouisIngenthron @bernardo_olafson
The manual pages (rather than scripting reference) is generally better for high level stuff. Pages like this one: https://docs.unity3d.com/Manual/ExecutionOrder.html
The overriding of the null comparison has been an oddity with many unexpected side effects and has been discussed for many many years. It's definitely a doozy :D
@LouisIngenthron @peterdrake the reason for this is that Monobehaviours live in the C# layer AND in the C++ layer of Unity. when you destroy a MB or set it to null the C++ layer gets removed from memory right away while the C# layer has to wait for Garbage Collection. In theory you can have MBs which are null in the C++ world but not in the C# world. Thats why its tricky to do null checks on MBs.