<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 Feb 25, 2016, at 3:07 PM, Joe Groff 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=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Feb 25, 2016, at 2:51 PM, Radosław Pietruszewski <<a href="mailto:radexpl@gmail.com" class="">radexpl@gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On 25 Feb 2016, at 23:47, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 25, 2016, at 2:43 PM, Radosław Pietruszewski <<a href="mailto:radexpl@gmail.com" class="">radexpl@gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On 25 Feb 2016, at 23:40, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 25, 2016, at 2:40 PM, Radosław Pietruszewski <<a href="mailto:radexpl@gmail.com" class="">radexpl@gmail.com</a>> wrote:<br class=""><br class="">Ah, that’s a neat idea! Not sure it’s an improvement though to have a magic type that changes how the compiler treats your method, rather than a rather explicit *attribute* on the method…<br class=""></blockquote><br class="">There's no magic. If you can't construct a value of your return type, you can't return.<br class=""><br class="">-Joe<br class=""></blockquote><br class=""><br class="">The magic is somewhere else. Calling a @noreturn function allows you to do things you can’t otherwise do:<br class=""><br class="">func foo() -> Int {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>fatalError()<br class="">}<br class=""></blockquote><br class="">I see. The unreachable code check arguably ought to also accept this if fatalError returns any uninhabited type, since it'll never be able return if that's the case.<br class=""><br class="">-Joe<br class=""></blockquote><br class="">Would that actually be useful today? (i.e. aside from your idea) To me, having a NoReturn return type seems more magic and less obvious than an attribute.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I admit I might be hopelessly in the language implementor's bubble here. From a semantic perspective, returning any uninhabited type (it doesn't need to be a specific one) feels less magic to me than having a special attribute or syntactic form for 'no return', since it achieves the desired semantics without additional language features. It also composes obviously with other aspects of function types like `throws` and currying (should we decide to add it back), whereas a special form needs to explicitly describe its interaction with those features.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><div class=""><br class=""></div>This makes perfect sense to me:<br class=""><div class=""><span style="font-family: arial, helvetica, sans-serif;" class="">func x() <b class="">noreturn </b></span><b style="font-family: arial, helvetica, sans-serif;" class="">throws -> T</b></div><div class=""><br class=""></div><div class=""><font face="arial, helvetica, sans-serif" class="">It could override a function that is not <b class="">noreturn</b>.</font></div><div class=""><font face="arial, helvetica, sans-serif" class=""><br class=""></font></div><div class=""><font face="arial, helvetica, sans-serif" class="">But it isn’t nearly common enough to warrant a qualifying keyword. Just from a language documentation perspective I would leave <b class="">@noreturn</b> as an attribute even though it’s technically part of the type.</font></div><div class=""><font face="arial, helvetica, sans-serif" class=""><br class=""></font></div><div class=""><font face="arial, helvetica, sans-serif" class="">-Andy</font></div></body></html>