I agree with Jaden and Xiaodi above—making Never a proper bottom type and using ?? would accomplish the same thing, and it&#39;s more general because it doesn&#39;t imply fatalError.<br><br>IMO, I don&#39;t think we should be making it *easier* to hide traps in our code. I don&#39;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 &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; 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) !! &quot;URL escaped paramString must be ASCII&quot;<br>
<br>
So Rien, I endorse this idea from the perspective of one who is !-averse.<br>
<br>
Cheers, P<br>
<br>
<br>
&gt; On Jun 27, 2017, at 12:44 PM, Rien via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; I would not use it.<br>
&gt; Somehow it gives me the creeps to leave something like ‘fatalError’ in a shipping application.<br>
&gt; During development it could make sense, but then again I like to keep development and shipping the same as much as possible.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Rien<br>
&gt;<br>
&gt; Site: <a href="http://balancingrock.nl" rel="noreferrer" target="_blank">http://balancingrock.nl</a><br>
&gt; Blog: <a href="http://swiftrien.blogspot.com" rel="noreferrer" target="_blank">http://swiftrien.blogspot.com</a><br>
&gt; Github: <a href="http://github.com/Balancingrock" rel="noreferrer" target="_blank">http://github.com/Balancingrock</a><br>
&gt; Project: <a href="http://swiftfire.nl" rel="noreferrer" target="_blank">http://swiftfire.nl</a> - An HTTP(S) web server framework in Swift<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt; On 27 Jun 2017, at 19:16, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; 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>
&gt;&gt;<br>
&gt;&gt; guard !lastItem.isEmpty else { return }<br>
&gt;&gt; let lastItem = array.last !! &quot;Array must be non-empty&quot;<br>
&gt;&gt;<br>
&gt;&gt; Details here:  <a href="https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b" rel="noreferrer" target="_blank">https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b</a><br>
&gt;&gt;<br>
&gt;&gt; Thank you for your thoughtful feedback, -- E<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <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>