Reasons to be careful with "implicit operator bool"

Unity Engine
1

Unity uses implicit operator bool to check if something is null.
Usually:

  public static implicit operator bool(Object obj)
     {
       return (obj != null);
     }

I think this is standard.
But I’m using an asset which defines this completely different:

  public static implicit operator bool(Object obj)
     {
       return (obj.gameObject.activeSelf == true);
     }

It doesn’t check that the object is null, but rather if it is active.
This caused hour of debugging to figure out where I was going wrong here by using “if (obj)”.
Is the lesson to avoid implicitly relying on “if (obj)” when possible, or is this just unusual programming done in the asset?

2

We developers rarely consider the huge amounts of money (in aggregate) that our decisions can cost.

This override is sheer dumbness.

2 Likes
3

Wait… did you write this operator?

Why?

For what reason?

4

I didn’t write it. It came with an asset I purchased.

5

ftfy

3 Likes
6

Thank god…

And no, it’s not the implicit operator that makes it bad. It’s the fact they used an implicit operator to hide extremely ridiculous functionality.

1 Like
7

It may just be because I like strong typing, but I’d never write something like if(object) instead of if(object == null). It gives me more control over what’s actually happening, and I think it’s more apparent what I’m trying to do.

EDIT: How hard would it have been to make a simple isActive() instead? Cut down hard on the confusion.

1 Like
8

Unity itself has some of these operators as well. The equality operator for Vectors is just particularly bad.

// UnityEngine.Vector3
public static bool operator ==(Vector3 lhs, Vector3 rhs)
{
    return Vector3.SqrMagnitude(lhs - rhs) < 9.99999944E-11f;
}

An equality operator should be checking for equality, period. The whole “but, but floats… shouldn’t compare those for equality” argument is a bad argument for mucking with equality at the operator level. A better decision would have been to provide a Vector3.Approximately function like they did with floats.

This cost me two days of debugging which I ranted about at the time, but it would be dangerous for them to change it at this point.

3 Likes
9

Agreed…

I actually had written my own Approximately method for vectors, assuming the equality was actual equality (an operation I would never have used…), then when looking at the source code of UnityEngine.dll one day I tripped over that and was like “what? really guys? it’s bad enough how you abused the == null and implicit bool of UnityENgine.Object… but this, this takes the cake.”

2 Likes
10

That was pretty much my reaction too. At least the behavior is documented though. I wouldn’t ever generally use it either, but the “set value and do stuff only if the new value is different” thing does come up occasionally.

11

You know Unity overides == too, so it’s not doing what you think it is. :wink:

I actually prefer to use the implicit book when I want to know if an object exists in the scene. That way I cant accidentally call the regular == null when I want the unity == null.

While we are talking about bad decisions, my favorite pet peeve is the implicit cast from a Vector3 to a Vector2. This cast looses information, and so should require explicit casting. Plus it makes Vector2 + Vector3 fail, making it relatively useless anyway.

1 Like
12

Those bastards!

1 Like