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

[Tony Allevato]

I agree with Jaden and Xiaodi above—making Never a proper bottom type and
using ?? would accomplish the same thing, and it's more general because it
doesn't imply fatalError.

IMO, I don't think we should be making it *easier* to hide traps in our
code. I don't think having to write a full guard/fatalError is all that bad
a thing—on the contrary, I want major failure points to stick out when I
read code. That being said, if some users want something like this, Never +
?? would get us there with something already planned for the language,
rather than introducing a new operator (for which the bar should be set
high).
On Tue, Jun 27, 2017 at 12:10 PM Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

> > it gives me the creeps to leave something like ‘fatalError’ in a
> shipping application
>
>
> Agreed, and I would use it for _exactly_ this reason.
>
> I avoid force unwrapping in production code, looking first for ways to
> gracefully handle the situation. Whenever I do use !, there is careful
> reasoning behind its use: “this is safe because p → q, and there is no
> reasonable way to handle this error because it cannot happen.” I take care
> to note this reasoning in a same-line comment, e.g.:
>
>    paramString.data(using: String.Encoding.ascii)!  // ASCII safe because
> paramString already URL escaped
>
> Such reasoning will, of course, eventually fail somewhere. It would be
> helpful to get runtime diagnostics on such a failure:
>
>    paramString.data(using: String.Encoding.ascii) !! "URL escaped
> paramString must be ASCII"
>
> So Rien, I endorse this idea from the perspective of one who is !-averse.
>
> Cheers, P
>
>
> > On Jun 27, 2017, at 12:44 PM, Rien via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > I would not use it.
> > Somehow it gives me the creeps to leave something like ‘fatalError’ in a
> shipping application.
> > During development it could make sense, but then again I like to keep
> development and shipping the same as much as possible.
> >
> > Regards,
> > Rien
> >
> > Site: http://balancingrock.nl
> > Blog: http://swiftrien.blogspot.com
> > Github: http://github.com/Balancingrock
> > Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> >
> >
> >
> >
> >
> >
> >
> >> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170627/4ba7f019/attachment.html>