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

[Dave DeLong]

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”)

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 <mailto: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 <https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b>
>> 
>> Thank you for your thoughtful feedback, -- E
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/dfcadcab/attachment.html>