I see a lot of people mentioning any sort of Cocoa interaction as a valid and frequent reason for force unwraps, but I'd also like to point out that using C APIs can also lead to potential force unwraps.
In a path library I'm working on, I try to make things as "safe" as possible before calling into C APIs, some of which may return NULL pointers. In several instances, I can eliminate any possible reason for the C APIs to return a NULL pointer (ie: the only C API requirement is for the path to be less than PATH_MAX), and so I use either a force unwrap or a guard let x = x else { fatalError("...") }.
There are plenty of APIs across C, Foundation, Cocoa, etc that return optionals, but that developers can relatively safely presume will not return nil and if they do return nil then a fatalError is the only appropriate solution.
I would like to see a solution to this that is less verbose than guard let x = x else { fatalError("...") }.
I'm not a big fan of:
x !! "Something went wrong"
because I'd like the ability to do more than just use fatalError. Sometimes it may be a recoverable error and so I'd just like to throw without having to write out a whole guard ... else ... block.
x !! fatalError("Something went wrong")
Is definitely more brief than the whole guard let x = x..., but still clear enough that anyone (beginner or veteran) should know what is going on.
As someone who is definitely not a Swift "expert", a
? with any kind of optional signifies a "safe" operation (AKA won't crash) and the nil-coalescing operator is taught on several beginner tutorials as "unwrap the optional or use the default value provided."
The ability to throw/crash to me just seems contrary to the intent of the ? which is why I am opposed to ?? using a Never return type. Doing so would require learning what Never is and why that means it's appropriate to use fatalError instead of the default value you were originally taught should go on the right-hand side of the ??.
On the other hand, ! is taught from the start as an "unsafe" operation (AKA may-crash). And so the !! operator makes logical sense to me.
Now once you get into some more advanced Swift topics you start to realize that these "beginner assumptions" aren't exactly true and that there is a lot more to the ! or ? than you originally thought, but as I read through this thread from the beginning it was brought up several times about how this proposal is meant to help beginners and how it shouldn't be confusing to beginners etc.
In my opinion, the ?? spelling with Never as the return type definitely makes this confusing for beginners who may only know that ! means unsafe and ? means safe. They may come across someone else's code and see that the supposedly "safe" ?? operation looks really dangerous with a fatalError on the rhs. It seems like a really bad idea to shatter their perceptions of ?-related operations in something as common as the nil-coalescing operator.
I actually really like @davedelong's idea:
I'm a huge fan of keeping ?? as "safe" as it currently is and introducing the ability to either throw or crash with ?! and !! respectively. If we had these 3 options, then I wouldn't be opposed to using just a string for the rhs of !!.