I think Brent beautifully captured opinions I share on force unwrapping. It has proven useful time and time again in helping me identify incorrect assumptions I've made.<br><br>Strong -1 to this proposal <br><br>Thanks,<br>Seth<br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 29, 2016 at 2:43 AM Joseph Lord via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As you point out there are there are circumstances where force unwrapping is required. Off the top of my head:<br>
<br>
1) Implementation of flatMap and other similar safe functions requires it or similar.<br>
2) Performance - in hot loops the conditionality may be a real performance penalty and other checks or outside knowledge may let you know that it is safe.<br>
3) Some people prefer to assert and crash in production and this is a valid option.<br>
<br>
Personally I only use the force unwrapping in test code where crashes are just untidy failures if they fail.<br>
<br>
If it is removed from the stdlib it could be implemented as a custom operator by those that want it but there would be a performance hit for calls from other modules as I don't think it could currently be inlined.<br>
<br>
I'm fairly neutral about whether this happens.<br>
<br>
Joseph<br>
<br>
> On Feb 28, 2016, at 7:53 PM, Developer via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Thanks all,<br>
><br>
> ~Robert Widmann<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>