<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="">I'd like to point out that while NoReturn does indicate that the function can't return, this works because a function that can't return may well declare any return type that it likes, not necessarily just NoReturn.<div class=""><br class=""></div><div class="">It's confusing to see `@noreturn func foo() -> Int`, but it's not much better to have a `func foo() -> Int` that doesn't return either.</div><div class=""><br class=""></div><div class="">I don't think that `func foo() throws -> NoReturn` is much clearer either. Does foo always throw, does foo call exit, or does foo enter an endless loop?</div><div class=""><br class=""></div><div class="">It seems to me that we're only slightly moving the ambiguity, so I see no compelling reason to implement this proposal. That'll be a -1 here.<br class=""><div class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 23 juin 2016 à 14:15:54, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md</a> ]</div><div class=""><br class=""></div><div class="">I am already on record as being against this proposal:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">Just because it can be modelled as a type doesn’t mean it’s the best way to represent the concept. It feels like uniformity for uniformity’s sake.<br class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func fatalError() -> NoReturn</div></blockquote><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">@noreturn func fatalError()</div></blockquote><div class=""><br class="">The first one probably isn't too hard to explain to a learner. The second one probably doesn’t need an explanation.</div></blockquote><div class=""><br class=""></div><div class="">(<a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/19958/" class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/19958/</a>)</div><div class=""><br class=""></div><div class="">A few more thoughts: I don't think uninhabited types actually come up very often (though non-returning functions are also pretty rare). I'm not against supporting composition for actual uninhabited types, but I don't think composition of NoReturn/Never is particularly interesting. I don't find throws<Never> compelling enough to add language support for it, but maybe I just can't think of a case where you want to be generic over error types.</div><div class=""><br class=""></div><div class="">Jordan</div></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=""></div></div></body></html>