[mikeash]

Objective-C is really fun here. Messages to nil are no-ops which return zero, which for booleans results in false. Thus, the conditional works just fine either way:

  if([userSuppliedInput isEqual: SOME_CONSTANT]) { ...

If userSuppliedInput is nil, the isEqual: returns false, and it works.

It gets really fun when both might be nil:

  if([a isEqual: b]) { ...

If a and b are both nil, then they're conceptually equal, but isEqual: still returns false because it's a mindless "always return 0 for messages to nil" thing that doesn't even look at any parameters passed in.

[efaref]

Not sure I like the sound of that. It sounds like the floating point wat of "NaN != NaN".

[koolba]

Or the SQL classic:

    NULL = NULL

It's not true or false, ... it's NULL!

[mikeash]

Making messages to nil be a no-op is certainly an "interesting" feature of Objective-C. It can make some code a lot more convenient to write, but it can also make certain bugs really difficult to track down.

After having done Swift for a while, I'm a big fan of using an option type so that "reference to object" is a different static type altogether from "reference to object, or nil."

[efaref]

Yes, I really like Rust and the way its Option<Box<T>> decays to a nullable pointer.