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><br>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><div class="gmail_quote"><div dir="ltr">On Tue, Jun 27, 2017 at 12:10 PM Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></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>
<br>
<br>
Agreed, and I would use it for _exactly_ this reason.<br>
<br>
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>
<br>
paramString.data(using: String.Encoding.ascii)! // ASCII safe because paramString already URL escaped<br>
<br>
Such reasoning will, of course, eventually fail somewhere. It would be helpful to get runtime diagnostics on such a failure:<br>
<br>
paramString.data(using: String.Encoding.ascii) !! "URL escaped paramString must be ASCII"<br>
<br>
So Rien, I endorse this idea from the perspective of one who is !-averse.<br>
<br>
Cheers, P<br>
<br>
<br>
> On Jun 27, 2017, at 12:44 PM, Rien via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I would not use it.<br>
> Somehow it gives me the creeps to leave something like ‘fatalError’ in a shipping application.<br>
> During development it could make sense, but then again I like to keep development and shipping the same as much as possible.<br>
><br>
> Regards,<br>
> Rien<br>
><br>
> Site: <a href="http://balancingrock.nl" rel="noreferrer" target="_blank">http://balancingrock.nl</a><br>
> Blog: <a href="http://swiftrien.blogspot.com" rel="noreferrer" target="_blank">http://swiftrien.blogspot.com</a><br>
> Github: <a href="http://github.com/Balancingrock" rel="noreferrer" target="_blank">http://github.com/Balancingrock</a><br>
> Project: <a href="http://swiftfire.nl" rel="noreferrer" target="_blank">http://swiftfire.nl</a> - An HTTP(S) web server framework in Swift<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
>> On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> 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>
>><br>
>> guard !lastItem.isEmpty else { return }<br>
>> let lastItem = array.last !! "Array must be non-empty"<br>
>><br>
>> Details here: <a href="https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b" rel="noreferrer" target="_blank">https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b</a><br>
>><br>
>> Thank you for your thoughtful feedback, -- E<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>