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 -Thorsten > Am 07.06.2016 um 22:43 schrieb Michael Peternell via swift-evolution > <[email protected]>: > > >> Am 07.06.2016 um 22:14 schrieb L Mihalkovic via swift-evolution >> <[email protected]>: >> >> >>>> On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >>>>> <[email protected]>: >>>>> >>>>>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution >>>>>> <[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. > >> >> I do hope the core team does pull ranks and goes with it. Frankly I have no >> stake in the name, and I would even argue that there might be a possible >> case for doing something even more un-explainable than this change: >> >> 1) create a protocol SwiftBottomType { } [ the core team might defend >> the idea that it should really be BuiltinBottomType, which I have no issues >> with ] >> >> 2) then create a enum NoReturn: SwiftBottomType {} >> >> When looking at this question and a couple of other related ones, a pattern >> should form, and the rational become self evident. >> >> >> >>> >>> -Michael >>> >>>> >>>> Charles >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
