<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I realize that this message might have more relevance in this list. Let me know if that is not the case.<br></div><div><br>Begin forwarded message:<br><br></div><blockquote type="cite"><div><b>From:</b> L Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com">laurent.mihalkovic@gmail.com</a>><br><b>Date:</b> June 8, 2016 at 7:49:22 AM GMT+2<br><b>To:</b> Thorsten Seitz <<a href="mailto:tseitz42@icloud.com">tseitz42@icloud.com</a>><br><b>Cc:</b> Michael Peternell <<a href="mailto:michael.peternell@gmx.at">michael.peternell@gmx.at</a>>, swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>, Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>>, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>>, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br><b>Subject:</b> <b>Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type</b><br><br></div></blockquote><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 6:57 AM, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div 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 strongly disagree. Type systems are not some esoteric academic thing only working for Haskell or functional languages. Just have a look at the type systems of other languages like Ceylon, Rust or TypeScript.</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=""><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 hope that Swift will someday have variance annotations for generic parameters and associated types so that we may express sound subtyping rules between generic types. A real bottom type will fit in there just nicely.</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=""><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 a real bottom type</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="">+1 for calling it Never</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 class=""><br class=""></div><div class="">+1 on all accounts (it is not the first time I find myself in agreement with many of the choices you support, and more interestingly, with the rational you use to support them: usually a mix between references to other examples and pragmatism).</div><div class=""><br class=""></div><div class="">here is another twist on Never… see further down...</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><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="">-Thorsten<span class="Apple-converted-space"> </span></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=""><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=""><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=""><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="">Am 07.06.2016 um 22:43 schrieb Michael Peternell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""><br class=""><blockquote type="cite" class="">Am 07.06.2016 um 22:14 schrieb L Mihalkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""><blockquote type="cite" class="">On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br 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?<br class=""></blockquote><br class="">"Never return". That's why it's in the return type slot, right after the `->`. 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 class="">+1 for @noreturn<br class="">We don't have to change it.<br class="">We have to keep it.<br class=""></blockquote><br class=""><br class="">this is so unfortunate… IMHO the proposal is the right move because it goes into the direction of unifying things in the language. the problem is that it is difficult to see it without looking at the language as a whole. then we realize that this can be connected to the change of dynamicType to a function or to the fact that .Type and .Self might also warrant a revisiting.<br class=""></blockquote><br class="">from a practical point of view, a @noreturn function is just so much different than any other function. this shouldn't be "unified". we can discuss if bottom types and normal types can be unified from a theoretical/academical point of view. but in the real world, a @noreturn function does not return at all, whereas most other function does return execution to its caller. To honor this view, a function that returns `Void` is meant to return, it just doesn't return any particular value. But `Void` should be the type with no values, not the type with exactly one value, so a function that returns `Void` shouldn't be able to return, because there can be no `Void` value. `Void` is an unconstructable type, and yet it is different from `@noreturn`. That would be a unification ;) . The whole concept of return-values is so much different in imperative programming than it is in Haskell and with "denotational semantics". Therefore we have 1) functions that return a value, e.g. `Int`, 2) functions that return no value (`Void`), and 3) functions that doesn't return at all (`@noreturn`) => I would like to keep it that way.<br class=""><br class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote></div></blockquote><div class=""><br class=""></div><div class="">Consider for a moment that the bottom type is a technical aspect of the runtime., the thing that the compiler needs so avoid some internal magic while steering towards expressing more things that can be expressed with protocols, using protocols. So that would give the compiler what it needs to have more internal symmetry. But then nothing says that our needs are the same as the compiler’s, particularly when it comes to expressivity. So that leaves us with the possibility of having a bottom type, and having something based on it that can present a more user friendly interface. And while we are at it, nothing says that the user facing side has to be universal, fitting all possible use cases. So then that opens up the possibility of </div><div class=""><br class=""></div><div class="">1) have a bottom type</div><div class="">2) have use site derived notions (the ones we users will learn) that are internally linkable to 1), but outside of what we care about</div><div class=""><br class=""></div><div class="">which bring us back to something like the following scenario:</div><div class=""><br class=""></div>1) create a <font face="Monaco" class="">protocol SwiftBottomType { } </font> [ the core team might defend the idea that it should really be <font face="Monaco" class="">BuiltinBottomType</font>, but the argument also goes that <font face="Monaco" class="">BuiltinXxxxLiteral</font> can be converted to <font face="Monaco" class="">SwiftXxxxLiteral</font> ]. This is something only the compiler cares about, but a building block for what we need. it would be simple to enforce in the compiler that SwiftXXXXX protocols cannot be the target of any user defined conformances if need be. </div><div class="">In fact, these <font face="Monaco" class="">SwiftXxxxxx </font>protocols could be considered so critical for the existence of the language/compiler (i.e. ‘below' the stdlib) that might might not even be represented in the sodlib, but directly manufactured into the <font color="#ff2600" face="Menlo" class="">TEXT.__swift3_</font><span style="color: rgb(209, 47, 27); font-family: Menlo;" class="">builtin</span> (don’t quote me on this one versus the meaning of the<font color="#e32400" face="Menlo" class=""> __swift2_proto???</font> can't recall its name at the moment) section of the libswiftRuntime.a (runtime lib already deals with all the metadata loading, low level existential, and internal reflection)</div><div class=""><br class=""></div><div class="">then :</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class="">BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinBooleanLiteralConvertible)</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class="">BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinExtendedGraphemeClusterLiteralConvertible)</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class="">BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinFloatLiteralConvertible)</div><div class="">...</div></div><div class=""><br class=""></div><div class="">can become (or stay as it is but, the point is that they are unified, and have become a pattern for future extensibility)</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class="">BUILTIN_CORE_PROTOCOL_(SwiftBooleanLiteralConvertible) // btw, they can all retain the BuiltinXxxxxxxx pattern</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class="">BUILTIN_CORE_PROTOCOL_(SwiftExtendedGraphemeClusterLiteralConvertible)</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class=""><div style="margin: 0px; line-height: normal;" class="">BUILTIN_CORE_PROTOCOL_(SwiftFloatLiteralConvertible)</div><div class=""><div style="margin: 0px; line-height: normal;" class="">BUILTIN_CORE_PROTOCOL_(<span style="font-size: 12px;" class="">SwiftBottomType</span>)<span class="Apple-tab-span" style="white-space:pre"> </span>// one of the the new guys</div></div><div class=""><br class=""></div></div></div><div class=""><font color="#12c00e" class=""><br class=""></font>2) then create a <font face="Monaco" class="">enum NoReturn: SwiftBottomType {} </font> that we learn about (and name it Never, or …. to match the returning situation. And as time goes, there may be other synonymous that will be built with the best possible user facing name for these circumstances.<br class=""><br class=""></div><div class=""><br class=""></div><div class="">When looking at this question and a couple of other related ones, a pattern should form, whose rational is self evident (I am listing a couple others in a separate doc just because IMHO it is a somewhat elegant binding for the low level)</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="orphans: auto; text-align: start; text-indent: 0px; widows: auto;" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></blockquote><blockquote type="cite" style="orphans: auto; text-align: start; text-indent: 0px; widows: auto;" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></blockquote><blockquote type="cite" style="orphans: auto; text-align: start; text-indent: 0px; widows: auto;" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></blockquote><blockquote type="cite" style="orphans: auto; text-align: start; text-indent: 0px; widows: auto;" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></blockquote><blockquote type="cite" style="orphans: auto; text-align: start; text-indent: 0px; widows: auto;" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></blockquote><blockquote type="cite" style="orphans: auto; text-align: start; text-indent: 0px; widows: auto;" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></blockquote><blockquote type="cite" style="orphans: auto; text-align: start; text-indent: 0px; widows: auto;" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></blockquote></div></blockquote></div><br class=""></div></blockquote></body></html>