> On Jun 7, 2016, at 7:21 PM, Jordan Rose via swift-evolution
> <[email protected]> wrote:
>
>
>>> On Jun 7, 2016, at 12:49, 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.
>
> I strongly agree. Just because it can be modelled as a type doesn’t mean it’s
> the best way to represent the concept. It feels like uniformity for
> uniformity’s sake.
>
> func fatalError() -> Never
>
> @noreturn func fatalError()
>
> The first one probably isn't too hard to explain to a learner. The second one
> probably doesn’t need an explanation.
>
> Jordan
All my +1s to this line of reasoning.
l8r
Sean
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
