<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=""><div class="">From that point of view, shouldn’t we then be talking about removing the postfix unary operator “<font face="Menlo" class=""><span style="font-size: 11px;" class="">!</span></font>”? With this proposal it could just as easily be replaced with: <font face="Menlo" class=""><span style="font-size: 11px;" class="">?? fatalError(“failed nil check”)</span></font>. But I don’t think anyone would take that suggestion seriously, so why are we not taking the idea of <font face="Menlo" class=""><span style="font-size: 11px;" class="">!!</span></font> seriously either?</div><div class=""><br class=""></div><div class="">I really like the idea of having both:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">let last = array.last ?? fatalError(“Reason”) // () → Never</span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">let last = array.last !! “Reason”</span></font></div><div class=""><br class=""></div><div class="">The first one fits with the idea of Nil Coalescing and explicitly failing because of a precondition failure. Or as Tony put it, it “leaves no other choice … but to do something that dies”. It leaves open the case of having the error removed at certain -O levels.</div><div class=""><br class=""></div><div class="">The second one fits with the idea of logical failure where <i class="">the operator itself</i> is doing the dying, just like the unary version. And, like the force unwrap operator, it wouldn’t be removed at -Ounchecked.</div><div class=""><br class=""></div><div class="">Dave</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 28, 2017, at 7:08 AM, 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="">The idea behind `?? () -> Never` is that it leaves no other choice in the nil case but to do something that dies, and that something is typically a function call like fatalError() that documents well enough the dying so !! would be unnecessary. And since it was pointed out above that this can be done today in the language with an autoclosure, I strongly believe that's the direction we should go vs. defining a new operator.<br class=""><br class="">In other words, !! doesn't fit with Never because it's not the *operator* that's doing the dying, but the right-hand side of that operator.<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jun 28, 2017 at 6:04 AM Erica Sadun 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"><div style="word-wrap:break-word" class="">I'll give this a kick around as soon as I get a moment and revise. I am slightly concerned that we discussed variations of this in the past (throwing if memory serves, with `Error` on the rhs) and that it broke the expectations of nil-coalescing. <div class=""><br class=""></div><div class="">In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can argue both ways, with the goal in reading code as "unwrap or die".<br class=""><div class=""><br class=""></div><div class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class="">-- E</div></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><br class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_1541409641460007210Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><div class="">The compatibility testing revealed no related errors. And the full test suite only shows one that I listed already.</div><div class=""><br class=""></div><div class="">Max</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 27, 2017, at 3:28 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_1541409641460007210Apple-interchange-newline"><div class="">This solution is nifty indeed, and has the chief advantage of working.<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" 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"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 27, 2017, at 1:03 PM, Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com" target="_blank" class="">adrian.zubarev@devandartist.com</a>> wrote:</div><br class="m_1541409641460007210m_-8152363839179283491Apple-interchange-newline"><div class=""><div class="m_1541409641460007210m_-8152363839179283491bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><p style="margin:15px 0px" class="">How about?</p><pre style="margin:15px 0px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal" class=""><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal" class="">public func ?? <T>(optional: T?, noreturnOrError: @autoclosure () throws -> Never) rethrows -> T {
switch optional {
case .some(let value):
return value
case .none:
try noreturnOrError()
}
}
</code></pre><div style="margin:15px 0px" class=""><br class="m_1541409641460007210m_-8152363839179283491webkit-block-placeholder"></div></div></div></blockquote></div></div><div style="word-wrap:break-word" class=""><div class="">Yeah, I saw your email right after I sent mine =)</div><div class="">This works, I tried it and also ran the test suite. There was only one error.</div><div class=""><br class=""></div><div class=""><font face="SFMono-Regular" class=""><span style="font-size:11px" class=""> var s: String = ns ?? "str" as String as String // expected-error{{cannot convert value of type 'NSString?' to expected argument type 'String?'}}<br class=""> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br class=""> cannot convert value of type 'String' to expected argument type 'NSString'</span></font><br class=""><br class=""><div class=""><br class=""></div><div class="">I now wonder what the effect on the source compatibility suite would be:</div><div class=""><a href="https://github.com/apple/swift/pull/10639" target="_blank" class="">https://github.com/apple/swift/pull/10639</a></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Max</div></div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="m_1541409641460007210m_-8152363839179283491bloop_original_html" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><div id="m_1541409641460007210m_-8152363839179283491bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div><br class=""><div id="m_1541409641460007210m_-8152363839179283491bloop_sign_1498593590478208000" class="m_1541409641460007210m_-8152363839179283491bloop_sign"><div style="font-family:helvetica,arial;font-size:13px" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div><br class=""><p class="m_1541409641460007210m_-8152363839179283491airmail_on" style="margin:15px 0px">Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution (<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a>) schrieb:</p><blockquote type="cite" class="m_1541409641460007210m_-8152363839179283491clean_bq" style="margin:15px 0px"><span style="margin-top:0px;margin-bottom:0px" class=""><div style="word-wrap:break-word" class=""><div class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px" class="">On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_1541409641460007210m_-8152363839179283491Apple-interchange-newline"><div style="margin-bottom:0px" class="">As you write, this operator becomes sugar for “?? fatalError()” once Never becomes a true bottom type.<br class=""><br class="">In the meantime, can’t the same thing be accomplished by overloading fatalError so it’s a generic function that returns a discardable result of type T, which in turn calls the Never-returning overload?<br class=""></div></blockquote><div class=""><br class=""></div><div class="">I like this idea more than adding an extra operator, but overloading fatalError won’t work now because of <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" style="margin:15px 0px" class=""><div style="margin-top:0px;margin-bottom:0px" class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="margin-top:0px;word-wrap:break-word" class=""><div 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?</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">guard !lastItem.isEmpty else { return }</font></div><div class=""><font face="Menlo" class="">let lastItem = array.last !! "Array must be non-empty"</font></div><div class=""><br class=""></div><div class="">Details here: <a href="https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b</a></div><div class=""><br class=""></div><div class="">Thank you for your thoughtful feedback, -- E</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br style="margin-bottom:0px" class=""></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></span></blockquote></div><div class="m_1541409641460007210m_-8152363839179283491bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"></div></div></blockquote></div></div>_______________________________________________<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>
</div></blockquote></div><br class=""></div>_______________________________________________<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" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></div>_______________________________________________<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>