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

[Jean-Daniel Dupas]

> Le 8 juin 2016 à 02:21, Jordan Rose via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>> 
>> On Jun 7, 2016, at 12:49, Michael Peternell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>> 
>>>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto: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.
> 
> 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.

+1 for keeping it as it is for the same arguments and many other arguments already details previously, like telling the function can return something that does not exists is not the same that telling it does not return or the fact that you can’t expect to code it purely in the standard library using type if you want to be able to warn on unreachable code let the compiler optimize based on the fact the function never returns (and does not return never).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/cadd21eb/attachment.html>