<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 Jun 8, 2016, at 7:49 AM, L Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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;"><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">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 class="" 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;">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 class="" 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;"><br class="" 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;"><span class="" 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;">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 class="" 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;"><br class="" 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;"><span class="" 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;">+1 for a real bottom type</span><br class="" 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;"><span class="" 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;">+1 for calling it Never</span><br class="" 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;"></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 class="" 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;"><span class="" 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;">-Thorsten<span class="Apple-converted-space"> </span></span><br class="" 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;"><br class="" 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;"><br class="" 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;"><blockquote type="cite" class="" 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;">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 { }<span class="Apple-converted-space"> </span></font> [ the core team might defend the idea that it should really be<span class="Apple-converted-space"> </span><font face="Monaco" class="">BuiltinBottomType</font>, but the argument also goes that<span class="Apple-converted-space"> </span><font face="Monaco" class="">BuiltinXxxxLiteral</font><span class="Apple-converted-space"> </span>can be converted to <font face="Monaco" class="">SwiftXxxxLiteral</font><span class="Apple-converted-space"> </span> ]. 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="" 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;">In fact, these<span class="Apple-converted-space"> </span><font face="Monaco" class="">SwiftXxxxxx<span class="Apple-converted-space"> </span></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<span class="Apple-converted-space"> </span><font color="#ff2600" face="Menlo" class="">TEXT.__swift3_</font><span class="" style="color: rgb(209, 47, 27); font-family: Menlo;">builtin</span> (don’t quote me on this one versus the meaning of the<font color="#e32400" face="Menlo" class=""><span class="Apple-converted-space"> </span>__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="" 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;"><br class=""></div><div class="" 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;">then :</div><div class="" 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;"><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;">BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinBooleanLiteralConvertible)</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;">BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinExtendedGraphemeClusterLiteralConvertible)</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;">BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinFloatLiteralConvertible)</div><div class="">...</div></div><div class="" 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;"><br class=""></div><div class="" 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;">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="" 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;"><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;"><br class=""></div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;">BUILTIN_CORE_PROTOCOL_(SwiftBooleanLiteralConvertible) // btw, they can all retain the BuiltinXxxxxxxx pattern</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;">BUILTIN_CORE_PROTOCOL_(SwiftExtendedGraphemeClusterLiteralConvertible)</div><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;"><div class="" style="margin: 0px; line-height: normal;">BUILTIN_CORE_PROTOCOL_(SwiftFloatLiteralConvertible)</div><div class=""><div class="" style="margin: 0px; line-height: normal;">BUILTIN_CORE_PROTOCOL_(<span class="" style="font-size: 12px;">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="" 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;"><font color="#12c00e" class=""><br class=""></font>2) then create a <font face="Monaco" class="">enum NoReturn: SwiftBottomType {}<span class="Apple-converted-space"> </span></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="" 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;"><br class=""></div><div class="" 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;">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></blockquote></div><br class=""><div class=""><br class=""></div><div class="">btw, I know that <span style="font-family: Monaco; font-size: 11px;" class="">BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_</span> have to be treated differently, but I think it is still possible to use the pattern they form to express other critically essential language notions via Protocols as opposed to contextual keywords (eg .Type .Self ) or some other types of secret hand-shakes.</div><div class=""><br class=""></div><div class="">For example at the moment they all are statically declared in the compiler, which also means that adding a new one requires recompiling the compiler, or that users cannot follow in the footsteps with their own literal convertibles (ours have to remain on the other side of a possible very smart thing the compiler would learn to do in the future). Which means that nothing says the following cannot be done</div><div class=""><br class=""></div><div class="">Replace :</div><div class=""><br class=""></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 style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class="">BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinIntegerLiteralConvertible)</div></div><div class="">...</div><div class=""><br class=""></div><div class="">with </div><div class=""><br class=""></div><div class=""><span style="font-family: Monaco; font-size: 11px;" class="">BUILTIN_CORE_PROTOCOL_(SwiftLiteralConvertible) <span class="Apple-tab-span" style="white-space:pre"> </span>// a single core protocol to flag for the compiler the entire literal convertible pattern</span><br class=""><div class=""><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;"><div class="" style="margin: 0px; line-height: normal;"><div class=""><div class="" style="margin: 0px; line-height: normal;">BUILTIN_CORE_PROTOCOL_(<span class="" style="font-size: 12px;">SwiftBottomType</span>)<span class="Apple-tab-span" style="white-space: pre;"> </span>// one of the the new core guys</div></div></div></div></div></div><div class=""><div class=""><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;"><div class="" style="margin: 0px; line-height: normal;"><div class=""><div class="" style="margin: 0px; line-height: normal;"><br class=""></div></div></div></div></div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class="">BUILTIN_SPECIALISED_PROTOCOL_(BuiltinBooleanLiteralConvertible, SwiftLiteralConvertible)</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Monaco;" class="">BUILTIN_SPECIALISED_PROTOCOL_(BuiltinExtendedGraphemeClusterLiteralConvertible, SwiftLiteralConvertible)</div></div><div class=""><br class=""></div><div class="">and then maybe the second type can be opened to us too… or these secondary definitions get out of the c++ code and back into the sodlib .swift code, which means that we can pattern some MyOwnSmartLiteralConvertibleThatISwearWillBehaveLikeYours after this model and have it equally discoverable as the lib's</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">reading your code is a very humbling experience.. I just think some additional symmetries might simplify things further.</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>