Time to wrap this pitch up. Apologies for the provocative OP, I’ve moderated my position since then. Along the way I’ve concluded:
-
Deprecating the force unwrap postfix operator is out of the question, source breaking changes to Swift at this point are out of scope. Many are still confident they are able to wield it with the discretion it requires though I’m not completely convinced. There is however a use case in less critical code bases such as for scripting.
-
Things might have been slightly better if Swift had adopted Kotlin's
!!
instead of!
as it would have been easier to audit for. -
It may be useful to create non-nilable initialisers for URL when it is initialised with a static string as this was so often the case-in-point.
-
I have continued to explore these alternatives in the Unwrap SPM package
-
I submitted the PR in the end to add a -warn-force-error option to the compiler though It was rejected pretty quickly as “the role of a linter”.
It even blew up on Twitter where you can gauge exactly what the broader community feels:
It is still my belief it's regrettable that force-unwrap is one of the first things developers new to Swift learn and likely one of the last to master. Having the vision to build nil-able types into a language and then negating much of the benefit with such a flimsy construct has pros and cons but in the end I came down of the side of “it does more harm than good”. If it's an assertion, require an annotation, add a bit of friction so it receives the attention it merits.
Replacing it with a guard is not quite the answer either. When debugging, nothing is worse than a section of code that fails silently so remember to log something to the console. I assume this is the origin of the belief that “safe” crashing is preferable but this doesn’t pan out well in the hands of users.
Thanks for the replies, All the best for 2021.