[swift-evolution] [Draft] Change @noreturn to unconstructible return type

[michael.peternell at gmx.at]

> Am 07.06.2016 um 22:14 schrieb L Mihalkovic via swift-evolution <swift-evolution at swift.org>:
> 
> 
>> On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> 
>>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution <swift-evolution at swift.org>:
>>> 
>>>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution