[swift-evolution] [Discussion]: Deprecate !-Unwrapping of Optionals

[Haravikk]

There are some cases where it’s still very useful even in pure Swift code. For example, say I have an array of optional values, and want to trip nils, then perform a transform on the result, I would do something like:

	let theResult = myArrayOfOptions.filter({ $0 != nil }).map({ doSomethingTo($0!) })

I could use if let inside the second closure, but it’d be messy; in fact, both that and using the ?? operator would require me to provide some kind of default, which isn’t possible if I have elements of arbitrary type. I could create a removeNils() method that returns a non-optional array (or lazy collection) but I’m not actually sure how to do that, and it’d definitely be more work than just using the exclamation point to tell the compiler “actually there are no optionals left at this point”.

> On 29 Feb 2016, at 02:54, Andrew Clissold via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I absolutely agree that force-unwrapping is ugly and dangerous, but I think it's still strongly needed for convenience when working with Objective-C APIs that haven't been audited for nullability. Of which there are still a very large amount :)
> 
> No new Swift code should make use of force unwrapping, but that should remain a developer convention rather than a compiler requirement for the time being.
> 
> Andrew
> 
>> On Feb 28, 2016, at 11:53 AM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Optional values pervade Swift code and so there is a significant part of the language dedicated to manipulating them and using them safely.  An optional value may be conditionally let-bound, guarded, pattern-matched on, given a default value with ??, or used with higher-order functions like map and flatMap without having to interact with partiality.  A corner case, however, remains in the form of the postfix-! force-unwrap operator.  At the term level, there is little reason to unwrap given the syntactic constructs above, and indeed code that does becomes brittle and, by its very nature, open to the dreaded "unexpectedly found nil while unwrapping an optional value" error (our very own NullPointerException).  In addition, bang is incredibly hard to spot in code bases that use it because it blends in with Boolean negation (which, in itself, is notoriously hard to spot in other C-like-languages), harming readability and making code review more difficult.  Finally, if the authors of a piece of code have such confidence in the existence of a value that they feel it safe to use force unwrapping, they should simply use a non-optional value and cut out a level of indirection and avoid the dangers of bang in the first place. 
>> 
>> Because of the above, I'd like to start a discussion about its deprecation and eventual removal in favor of either an unsafeUnwrap function or other extra-syntactic constructs.  I don't intend for force-unwrapping as a concept to go away, as there will always be corner cases where it is necessary, but I don't believe it deserves to be so easy to do in a language that holds safety as a core tenant.