> 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
