> On Jun 8, 2016, at 7:49 AM, L Mihalkovic <[email protected]> wrote: > >> >> On Jun 8, 2016, at 6:57 AM, Thorsten Seitz <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. >> >> 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. >> >> +1 for a real bottom type >> +1 for calling it Never > > +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). > > here is another twist on Never… see further down... > > >> >> -Thorsten >> >> >>> Am 07.06.2016 um 22:43 schrieb Michael Peternell via swift-evolution >>> <[email protected] <mailto:[email protected]>>: >>> >>> >>>> Am 07.06.2016 um 22:14 schrieb L Mihalkovic via swift-evolution >>>> <[email protected] <mailto:[email protected]>>: >>>> >>>> >>>>>> On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >>>>>>> <[email protected] <mailto:[email protected]>>: >>>>>>> >>>>>>>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution >>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> 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? >>>>>>> >>>>>>> "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. >>>>>>> >>>>>>> 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*. >>>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>> >>>>> +1 for @noreturn >>>>> We don't have to change it. >>>>> We have to keep it. >>>> >>>> >>>> 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. >>> >>> 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. >>> >>>> > > 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 > > 1) have a bottom type > 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 > > which bring us back to something like the following scenario: > > 1) create a protocol SwiftBottomType { } [ the core team might defend > the idea that it should really be BuiltinBottomType, but the argument also > goes that BuiltinXxxxLiteral can be converted to SwiftXxxxLiteral ]. 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. > In fact, these SwiftXxxxxx 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 > TEXT.__swift3_builtin (don’t quote me on this one versus the meaning of the > __swift2_proto??? 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) > > then : > BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinBooleanLiteralConvertible) > BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinExtendedGraphemeClusterLiteralConvertible) > BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinFloatLiteralConvertible) > ... > > can become (or stay as it is but, the point is that they are unified, and > have become a pattern for future extensibility) > > BUILTIN_CORE_PROTOCOL_(SwiftBooleanLiteralConvertible) // btw, they can all > retain the BuiltinXxxxxxxx pattern > BUILTIN_CORE_PROTOCOL_(SwiftExtendedGraphemeClusterLiteralConvertible) > BUILTIN_CORE_PROTOCOL_(SwiftFloatLiteralConvertible) > BUILTIN_CORE_PROTOCOL_(SwiftBottomType) // one of the the new > guys > > > 2) then create a enum NoReturn: SwiftBottomType {} 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. > > > 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)
btw, I know that BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_ 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. 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 Replace : BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinBooleanLiteralConvertible) BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinExtendedGraphemeClusterLiteralConvertible) BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinFloatLiteralConvertible) BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinIntegerLiteralConvertible) ... with BUILTIN_CORE_PROTOCOL_(SwiftLiteralConvertible) // a single core protocol to flag for the compiler the entire literal convertible pattern BUILTIN_CORE_PROTOCOL_(SwiftBottomType) // one of the the new core guys BUILTIN_SPECIALISED_PROTOCOL_(BuiltinBooleanLiteralConvertible, SwiftLiteralConvertible) BUILTIN_SPECIALISED_PROTOCOL_(BuiltinExtendedGraphemeClusterLiteralConvertible, SwiftLiteralConvertible) 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 reading your code is a very humbling experience.. I just think some additional symmetries might simplify things further.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
