I wish the ? operator worked on GameObject

Unity Engine
,
1

I wish this code would work, it would be so useful!

public GameObject player;
player?.transform.position = Vector3.zero; // Auto null-check
2

me too…

Everything about how Unity deals with ‘null’ drives me nuts.

Just tonight I was wrestling with that annoying thing where unity assigns an actual object to any UnityEngine.Object field that is serialized if it’s null when serialized. The object is a ‘dead’ object that evaluates true if you compare it to ‘null’, but there’s an actual C# object sitting there. And since the ‘== null’ operator doesn’t work if you type it to System.Object, you can get false positives.

Grrrrrrrrrrr.

Like why Unity, why do you have to stick an object in if it’s null? Leave it null!

1 Like
3

I was about to critique you for misusing the ternary operator before I did a quick Google check. You taught me something new!

4 Likes
4

Unfortunately the ?. is not overloadable, otherwise I expect Unity would have handled it along the lines of ==.

See the article in my second link. They have some really good reasons for doing what they do.

Edit: To clarify, they were good reasons back when the decisions were made. With current versions of C# I’m not sure that the same decisions would be ideal.

1 Like
5

Their reason is this:

And I don’t agree that’s a good reason.

It is certainly a reason, but ‘good’ is subjective.

I’m of the opinion that early on they made a bunch of choices based on making “novice” lives better, well punishing professional level developers. But since their target audience was novices at first, it worked for them. Now as their user base has matured, they’re taking the hit for that.

Mind you, when I said:

I was being rhetorical. I am aware of the article you posted. I just think all those choices they made back then are terrible choices. They’re up there with how Mesh.vertices, Renderer.material, etc, returns clones/dupes/added behaviour. Nothing about the property naming conveys that it’s creating a clone and because it’s a property you feel as if you should be able to directly manipulate it, but actually you can’t (depending the property). Better named methods like ‘CopyVertices’ and ‘SetVertices’ would be more descriptive. This is a much longer rant I’ve had elsewhere on these forums though, so I’m going to leave it there.

In the same sense… I understand why they still exist. And we have to deal with our bad choices down the line. Changing the API now breaks existing code bases… so doing so has to be deliberate, slow, and with the communities understanding. So they don’t break code bases.

But pretending they were “good” choices doesn’t help at all.

6

It was a good choice back then. It wouldn’t be a good choice today.

BTW, on that note, I really don’t like this notion that Unity does not take up the decision and introduce breaking changes on major version change. After the LTS version it’s a good place to introduce this kind of things.

The user base always will demand everything and double that. Asset store creators also always will ask for zero change to not to create extra work for them.
But staying on old decisions fearing to break old code is bad. If the old code is important, one should stay on the last LTS, problem solved.
Also if AS Publishers want to support new Unity version, then they should work on it, otherwise they support last LTS version.

So if I can piggy-bank on this, I would add to the wish-list, that the old debts should be paid at major version changes.

4 Likes
7

Hah, funnily enough I was trying the same thing yesterday.
Yeah I agree, this would be a nice addition.

1 Like
8

The ? operator and the bogus null objects are seperate issues.

The ? operator doesn’t work because you can’t overload ?, while you can overload ==. I they changed the == overload, checking for destroyed objects would be much less convenient, so it’s for sure not a free trade off.
There’s two real choices - either (x == null) also checks if x is destroyed, or (x?.a) works for UnityEngine.Object types. I prefer x == null working as it does.

The bogus null objects only exist in the editor, and are there in order to give you MissingReferenceExceptions with helpful error messages (“There’s no X component attached”) instead of NullReferenceExceptions. Those don’t exist in builds, and are the reason why every GetComponent call in the editor that doesn’t find the component causes 0.6 kb of allocation.
This is insanely bad, especially due to giving different results in the editor and at runtime. This should be purged with fire.

2 Likes