The Brilliance of “nil” in Objective-C

You can literally never trust anything - ever - is not nil because `nonnull` is just a hint, and messaging nil will never crash. It'll just return 0 (or {0} or 0.0 depending on context), which is sometimes valid - and sometimes a horrible failure mode. Failing silently like that is the worst option.

As such you end up having a ton of boilerplate all over the place checking the validity of input parameters to methods and initializers for conditions which shouldn't be representable in the first place - even when the method signature warrants that it's not representable, because it still won't crash on ya.

Let's say you have a chain of property accessors, a.b.c.d, the where d is a float. They're all supposed to be nonnull. You get 0.0. Is that valid? Shrugasaurus rex. Time for the ol' NSParameterAssert(a.b.c != nil).

[edit] Also, canonically, there's 5+1 'null' values: nil, Nil, NULL, -[NSNull null] and 0 - plus nullptr in Objective-C++.

As someone who has been building on Objective-C for >10 years now... it's horrible. Sure, there's less compiler-yelling-at-you-itis, but the code sample the author gives is almost certainly the single biggest source of bugs in Objective-C codebases.

The inclusion of Optionals in Swift is specifically to, in one fell swoop, eliminate the single largest source of bugs in Obj-C codebases.

I get the appeal of getting the compiler to be less strict and yell at you less for just hacking around - but something you use to write production code needs be very liberal about error detection and yelling at you.

Not to mention the same lack of verbosity is supported in Swift with all of the safeties of optionals:

`if dict?.keys.contains("a")`

Which is both semantically and typographically terser, and makes the intention of the code clear (i.e., "dict" is expected to sometimes be nil)

- (id)thingThatSometimesWorks:(NSError *)error;

You can chain these to your heart's content. The one that fails sets the error and returns nil; following messages are sent to nil which does nothing and a particular characteristic of doing nothing is that it doesn't overwrite the error that was set. So you still get to see the error when the workflow finishes.

As an objective-C programmer, I also have a tool in my toolbox which gives NSNull the same message-swallowing behaviour as nil.

@implementation NSNull(GJLNilReceiver)

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector { return [super methodSignatureForSelector:aSelector] ?: [NSMethodSignature signatureWithObjCTypes:"@@:"]; }

- (void)forwardInvocation:(NSInvocation *)anInvocation { [anInvocation invokeWithTarget:nil]; }

@end

var a : T; // cannot be null

var b : T?; // can be null

a.something; // OK

b.something; // not possible because b could be null

b!!.something; // assert that b is not null, then do the stuff

b?.something; // if b is null, return null, else do the stuff

So, each time you see the "?." you know to take extra care with that statement. On the other hand it's very short and easy to write chains of function calls that could return null which then falls through.

And therein lies the root error which makes this entire blog post misguided.

Trivial (hopefully) question:

Would you rather fix 1 bug that takes 10 minutes to find, or 10 bugs that take 20 seconds each?

Given that 'my code silently just... does.... nothing? That's odd' is tens to perhaps even a hundred times harder to find than 'you assumed this could not be null, right on this very line right here, here is the full stack trace how we got there - it IS null' - NPE is superior to this silent treatment.

That's not to say runtime-only null checking (e.g. java without nullity annotations for example) is the only right answer. Far from it.

But it's superior to leaving a trail of ticking time bombs like this.

In effect, you make a difference choice about the semantic meaning of it.

In Objective C, `nil` means: "A sentinel object that is real, has semantic meaning, and that meaning is that it returns nil for all things". Woe is you if you treat it as "An object that indicates the value is unknown or does not apply (no interaction with it was ever expected)".

In java, `null` means: "A sentinel value that indicates the value is unknown/unset or does not apply - hence any attempt to interact with it will throw an error". Woe is you if you treat it as a sentinel. But less woeful - you simply get an exception pointing at the line where you made the brainfart.

Unfortunately lots of program language ecosystems aren't quite as clear about what nil/null is supposed to actually mean (e.g. java where it's often used as sentinel, and then leads to code littered with `if (x == null || x.isEmpty())` style lines, a clear sign someone is not sticking to a meaning of `null` that works well with that particular language.

If something can be nil, handle the case. There’s nothing brilliant about objective-C’s nil kludge.

  typedef std::optional maybe;
  using nil = std::nullopt;
 

When you combine those with an “either” function which returns either a maybe<T> else a default T, you end up with a nice way of having default args in C++. Everything defaults to nil, then you set it to either(foo, defaultFoo()) in the body of the function.

Of course, C++ already has what it calls default arguments. But lisp has corrupted me. The defaults can’t be a function call, and the values can’t refer to other arguments, so they feel useless.

Heckin C++. I feel like programmers 80 years from now will still be yearning for an escape, whereas C++100 will still be the dominant systems programming language. Golang was a nice attempt, and so is Rust, but empirically the evidence is that (at least in AI) you can’t escape C++. The best thing to do is to just dive in.

Some languages allow you to say “this can never be null”, and in general, i find that really helpful and ergonomic but there’s cases where it’s not practical and you have to permit null and at that point, you’ve sunk the boat.

Strict non-nullable with Option types has been moved to 2nd place solution since i experienced nil punning.

Treat nil as a value, like in this article’s example of the array being terminated by nil. Don’t make it an exception to compare against nil. But don’t ascribe any other meaning to the value - that means no matter the context, nil can semantically fit your use case.

It’s better than option primarily because it means a lot less code. You delete all “is this value present?” type code from your codebase because encountering nil in your happy path is rendered harmless.

Very nice.

In Swift, you can call methods on Optional values, and they evaluate to null or the actual value. So the authors example:

if (dict.containsObjectForKey[@"a"]) { ... }

Would look like this:

if dict?.contains("a") { ... }

The `?` tells Swift to only call `contains` if `dict` is not null. The return value of this call would then be another optional. This second point is the improvement over Objective-C. There, you would not know whether the return value of `dict.containsObjectForKey` is a potential null value. This, in turn, would crash the app if you'd try to use this return value to, say index into an array or perform math on it. In Swift, the compiler yells at you to remind you that this value can be null.

So, really, Swift has the same benefits, but better.

The literal syntax `@[ ... ]` gets transformed into an initializer call, which throws an exception if it is passed a `nil` value. And I can't remember, but I would expect the compiler to at least warn, if not error, if you put a literal `nil` in there.

If programmers today treated software like a car, they would blow up the car every time the air conditioner button didn't work. Desktop and console apps work this way.

Perfect is the enemy of the good, many times your app isn't running a nuclear reactor, and even if it was you might want it actually be able to recover from a failure. Think Erlang.

Is this line the victim of an overeager s/pre/code/g I wonder…

    if (dict != nil && dict.containsObjectForKey[@"a"]) { ... } 
    Can become this:
    if (dict.containsObjectForKey[@"a"]) { ... } 
    This is probably the least-Swift thing ever, but, if you're used to coding in this style, it's fantastic

if foo || bar || baz || you_do_not_even_know_what_comes_next break

or:

retval = foo || bar || baz || you_do_not_even_know_what_comes return retval

&c

I don't understand why it's notable except that it's not really JS or Pythonic . . .

dict.containsObjectForKey[@"a"]

Becomes roughly

dict?.containsObjectForKey(“a”) == true

Also, the author admits there are two kinds of null in Swift, as compared to four in Obj-C. Is the second kind he's referring to `NSNull`? Doesn't that only exist to bridge with Obj-C APIs that haven't been updated yet? That's pretty misleading, if so.

I sort of prefer Swift:

let array = [“a”,”b”]

On the other hand, if NULL is not an expected value, then how often do you really find the logic error at the same spot that the panic occurred? Not very often in my experience. We have callstacks for a reason. You usually find the NullPointerException at the bottom of the stacktrace or the None.panic() after 100-something other function calls in significantly complex codebases. No, if a function expects a value 100% of the time, and it was passed a NULL value, that's the caller's problem. And Option<T> won't help you if the user-facing calling code is still passing None or std::nullopt for whatever misguided or erroneous reason they may be doing so.

Certainly I agree there're benefits to encoding this kind of behaviour into the type system, but I don't agree that it's ultimately a solution to the '4 billion dollar mistake', since mistakes ultimately still happen. You just swap NULL for None and you still have a bug in your logic, just no longer a bug in the types. It's kicking the can.

Other things too but I’m too lazy (forgive the clickbait title):

https://vadosware.io/post/how-and-why-haskell-is-better/

PS: The co-existence of nil, Nil, NULL and NSNull was just unfortunate.

    dict.setObjectForKey(@"b", @"a");
    assert(dict.containsObjectForKey[@"a"]);

In Python, I often found that it is helpful to also have a separate "None"-like type despite None, which I called NotSpecified. Often in functions you have sth like:

    def func(opt: int = None):
       if opt is None:
           opt = get_default_opt()
       ...

    def func(opt: Optional[int] = NotSpecified):
        if opt is NotSpecified:
           opt = get_default_opt()
        ...

    my_dict.get("foo", NotSpecified)

Maybe.