<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 27, 2017, at 1:43 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">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.<br class=""><br class="">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).<br class=""></div></blockquote><div><br class=""></div><div>I disagree that this is making hiding traps easier. It’s asking you to put in two exclamation points instead of only one to force unwrap, along with an explanation of why you think it’s ok to be doing so. That’s much more “in your face” than “<font face="Menlo" class=""><span style="font-size: 11px;" class="">array.last!</span></font>”.</div><div><br class=""></div><div>Dave</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jun 27, 2017 at 12:10 PM Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> it gives me the creeps to leave something like ‘fatalError’ in a shipping application<br class="">
<br class="">
<br class="">
Agreed, and I would use it for _exactly_ this reason.<br class="">
<br class="">
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.:<br class="">
<br class="">
paramString.data(using: String.Encoding.ascii)! // ASCII safe because paramString already URL escaped<br class="">
<br class="">
Such reasoning will, of course, eventually fail somewhere. It would be helpful to get runtime diagnostics on such a failure:<br class="">
<br class="">
paramString.data(using: String.Encoding.ascii) !! "URL escaped paramString must be ASCII"<br class="">
<br class="">
So Rien, I endorse this idea from the perspective of one who is !-averse.<br class="">
<br class="">
Cheers, P<br class="">
<br class="">
<br class="">
> On Jun 27, 2017, at 12:44 PM, Rien via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> I would not use it.<br class="">
> Somehow it gives me the creeps to leave something like ‘fatalError’ in a shipping application.<br class="">
> During development it could make sense, but then again I like to keep development and shipping the same as much as possible.<br class="">
><br class="">
> Regards,<br class="">
> Rien<br class="">
><br class="">
> Site: <a href="http://balancingrock.nl/" rel="noreferrer" target="_blank" class="">http://balancingrock.nl</a><br class="">
> Blog: <a href="http://swiftrien.blogspot.com/" rel="noreferrer" target="_blank" class="">http://swiftrien.blogspot.com</a><br class="">
> Github: <a href="http://github.com/Balancingrock" rel="noreferrer" target="_blank" class="">http://github.com/Balancingrock</a><br class="">
> Project: <a href="http://swiftfire.nl/" rel="noreferrer" target="_blank" class="">http://swiftfire.nl</a> - An HTTP(S) web server framework in Swift<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
>> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>> 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?<br class="">
>><br class="">
>> guard !lastItem.isEmpty else { return }<br class="">
>> let lastItem = array.last !! "Array must be non-empty"<br class="">
>><br class="">
>> Details here: <a href="https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b" rel="noreferrer" target="_blank" class="">https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b</a><br class="">
>><br class="">
>> Thank you for your thoughtful feedback, -- E<br class="">
>><br class="">
>> _______________________________________________<br class="">
>> swift-evolution mailing list<br class="">
>> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>