Wouldn't you prefer seeing:
foo .? bar . baz .? roo
Why not make the nil check (or error silencing) explicit when it is so cheap to do so?
I think that Javascript's silencing of wrong parameter counts, Perl's (non-strict) allowing string concat, and non-well-founded implicit coercions (i.e: ones that change the semantics of the value) are all terribly horrible.
I believe that those who value convenience over safety deserve neither and will lose both.
The reasons that is defensible in message passing systems is because such systems are basically recapitulations of computer networks, and object nullity is equivalent to a network partition. That's the kind of failure mode that you handle in the policy layer, which is above the runtime layer in an application system just as it would be above the network layer in a distributed system.
Our team is split (I don't know how evenly) on whether Obj-C or Swift's behavior is better. There are some staunch defenders of Obj-C's pattern being better.
I personally prefer requiring the programmer to explicitly handle nil/null. I think it improves maintainability, because future developers can see the code is correct, and it protects against changes (ex: you knew nil could never happen when your code was written, but then someone changed it so nil does occur and now your code is broken). It also saves future developers from spending time reasoning about the behavior of the code when nil occurs.
The distinction is between segfault and returning 0 bits, and I'd say that returning 0 bits is generally better, because most of the time, in iOS apps, especially in absence of a "??" operator, it's what you want. For example, in a table view data source you don't have to check if your data array is non-null, just return its count, it'll be 0 if it is.
i.e. Optional monad > return all 0 bits > segfault
My go-to example in favor of the idea would be languages and libraries where 'null' and 'empty list' cause the same behavior in list-processing functions.
if (input.isInvalid()) {
reject()
} else {
accept()
}
The other main complaint is when you have a long string of methods unexpectedly turn out nil at the end, it's a pain to figure out which one it was.
nil is a pointer to the value 0, and in C there is only one value that evaluates to a logical false, which is 0. Invoking a method on nil returns 0. This itself alleviates the kind of nil-check-chains discussed in this thread:
[[[user profile] name] isEqualToString:@"Paul"];
[user profile] && [[user profile] name] && [[[user profile] name] isKindOf:NSString] && [[[user profile] name] isEqualToString:@"Paul"];
(int)nil == 0 <?php
$foo = array();
echo $foo['a']['b']['c']; // not an error echo $foo['a']['b'] ?? 'default_value'; $v = @first($var1, $var2, 'some-default');
d = lambda {|hash,key| Hash.new(&d) }
foo = Hash.new(&d)
p foo['a']['b']['c']
Of course it's likely to blow up in all kinds of ways since anything trying to do "if foo['a']" to check of 'a' is present in foo will break, for example.
My argument for this is you should design for the most common use case first, and most commonly people will want '.?' behavior. You can still check explicitly for null in the other cases, or even introduce a more cumbersome non-safe navigation operator. The resulting code will overall need fewer checks, be more readable, you'll have fewer crashes and exceptions, and it will generally do the right thing.
I occasionally write toy languages and this is one behavior I think I got right recently. Along the same lines, but as a more extreme measure, I would argue that invoking a method call on a null object should return null instead of throwing an exception.