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

[Seth Friedman]

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.

Strong -1 to this proposal

Thanks,
Seth
On Mon, Feb 29, 2016 at 2:43 AM Joseph Lord via swift-evolution <
swift-evolution at swift.org> wrote:

> As you point out there are there are circumstances where force unwrapping
> is required. Off the top of my head:
>
> 1) Implementation of flatMap and other similar safe functions requires it
> or similar.
> 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.
> 3) Some people prefer to assert and crash in production and this is a
> valid option.
>
> Personally I only use the force unwrapping in test code where crashes are
> just untidy failures if they fail.
>
> 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.
>
> I'm fairly neutral about whether this happens.
>
> Joseph
>
> > On Feb 28, 2016, at 7:53 PM, 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.
> >
> > Thanks all,
> >
> > ~Robert Widmann
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160229/3a72f8f3/attachment.html>