[swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

Adrian Zubarev adrian.zubarev at devandartist.com
Tue Jun 27 14:53:24 CDT 2017


Can’t we simply overload ?? to support @autoclosure () -> Never now and remove that overload when Never is the bottom type? Syntactically it would look and do the same.



-- 
Adrian Zubarev
Sent with Airmail

Am 27. Juni 2017 um 21:52:01, Matthew Johnson via swift-evolution (swift-evolution at swift.org) schrieb:


On Jun 27, 2017, at 2:49 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:


On 27 Jun 2017, at 20:23, Dave DeLong via swift-evolution <swift-evolution at swift.org> wrote:

Also a +1 from me. This is something I always put in to my code.

I agree that having `Never` as a bottom type is interesting, but even if that were the case, the proposed “!!” operator is still useful, because it short-circuits having to fatalError() myself. IE:

let last = array.last ?? fatalError(“array must not be empty”)

The above solution with Never is the better solution IMHO:

No new operator
More flexible: what if you want something else than a fatalError? For example, I might want to define a logAndFatalError() function which stores the error to a log file before trapping.

+1


vs

let last = array.last !! “Array must not be empty"

I also think having it “fatalError” in shipping code is fine, because it’s equivalent to what would happen if you incorrect force-unwrap.

Dave

On Jun 27, 2017, at 12:08 PM, Zach Waldowski via swift-evolution <swift-evolution at swift.org> wrote:

Big +1.

Using `!` is widely seen as a smell. However, the need for it still arises; they are preconditions, of a sort. It has become prevalent in my teams’ codebases to do “guard else preconditionFailure”.

I like `!!` over something like `?!`; it follows the pattern that almost every `?` in the language has an equivalent `!`.

The implementation details are ultimately not relevant to me. I’m a fan of `Never` being a bottom type for more reasons than just this. I also see no reason why operator funcs couldn’t accept file and line as extra arguments on the rhs.

Best,
  Zachary Waldowski
  zach at waldowski.me

On Tue, Jun 27, 2017, at 01:16 PM, Erica Sadun via swift-evolution wrote:
Using an operator to provide feedback on the context of a failed unwrap has become a commonly implemented approach in the Swift developer Community. What are your thoughts about adopting this widely-used operator into the standard library?

guard !lastItem.isEmpty else { return }
let lastItem = array.last !! "Array must be non-empty"

Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b

Thank you for your thoughtful feedback, -- E

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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/20170627/ad45a748/attachment.html>


More information about the swift-evolution mailing list