[e28eta]

I would simply point to Apple's new language, Swift, dropping that feature as proof that they don't think it's the best way to design a language.

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.

[cballard]

I prefer Optional to implicit nullability, but the debate isn't really between Optional and implicit nullability (is there any question there?).

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