<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div></div><div>On the other hand...</div><div><br></div><div>The first is rather clever and beautiful looking...making it somewhat Swifty.&nbsp;</div><div><br></div><div>I never cared for annotations:</div><div>- they make it look noisy&nbsp;</div><div>- they seem like a "hack" rather than a true part of the standard library</div><div><br></div><div>Also technically,&nbsp;</div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">@noreturn func fatalError()</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div>can be modeled as (I think?):</div><div><span style="background-color: rgba(255, 255, 255, 0);">@noreturn func fatalError() -&gt; Void</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">which doesn't make much sense.&nbsp;</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Also, could this fix this issue:</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">"That said, you can’t override a function or method that is marked with the&nbsp;<code class="code-voice" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; word-break: break-all; word-wrap: break-word;">noreturn</code>attribute with a function or method that is not. Similar rules apply when you implement a protocol method in a conforming type."</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">&nbsp;</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Overriding a method without this as an attribute could allow this. I'm not sure if this is something people would need though or if it even makes sense.&nbsp;</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Brandon&nbsp;</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><br>On Jun 7, 2016, at 8:21 PM, Jordan Rose via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 7, 2016, at 12:49, Michael Peternell via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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">Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;:<br class=""><br class=""><blockquote type="cite" class="">On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class="">I disagree. We are discussing how to annotate a function in some way so that the compiler knows that the code following it will never be executed *and* so a human who reads the declaration knows that it does not return. “Never" is a poor choice for that. Never what? Never return? Never use this function? Never say never again?<span class="Apple-converted-space">&nbsp;</span><br class=""></blockquote><br class="">"Never return". That's why it's in the return type slot, right after the `-&gt;`. If you read it out loud, you'll read "returns Never", which is exactly correct.<br class=""><br class="">NoReturn, on the other hand, does *not* read well in that slot: "returns NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes no sense whatsoever *as a type name*.<br class=""></blockquote><br class="">But it’s *not* a type. You’ll never have an instance of it. Since it’s not a type name, it doesn’t make sense that it needs to look like one. What it is doing is telling you something about the behavior of the function itself, not its return value. Its return value, if there were one, is irrelevant, since the function, by its very nature, will never even get to the point where it would return it. Either it’s going to kill the app via a fatalError or something, or we have something like dispatch_main() which will keep executing until the program stops, and one way or another, it won’t return.<br class=""><br class="">For that reason, frankly, I don’t understand why we want to change this from being an attribute, which seems to me the more natural and logical choice to describe this behavior. If we *do* have to change it, though, NoReturn conveys the most clearly to the reader what it does.<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="">+1 for @noreturn</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=""><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="">We don't have to change it.</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=""><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="">We have to keep it.</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><br class=""><div class="">I strongly agree. Just because it <i class="">can</i>&nbsp;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.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func fatalError() -&gt; Never</div><div class=""><br class=""></div><div class="">@noreturn func fatalError()</div></blockquote><div class=""><br class=""></div>The first one probably isn't too hard to explain to a learner. The second one <i class="">probably&nbsp;doesn’t need an explanation.</i><div class=""><br class=""></div><div class="">Jordan<div class=""><br class=""></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>