[swift-evolution] Idea: change "@noreturn func f()" to "func f() noreturn"

[Andrew Trick]

> On Feb 25, 2016, at 3:07 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Feb 25, 2016, at 2:51 PM, Radosław Pietruszewski <radexpl at gmail.com> wrote:
>> 
>>> On 25 Feb 2016, at 23:47, Joe Groff <jgroff at apple.com> wrote:
>>> 
>>> 
>>>> On Feb 25, 2016, at 2:43 PM, Radosław Pietruszewski <radexpl at gmail.com> wrote:
>>>> 
>>>>> On 25 Feb 2016, at 23:40, Joe Groff <jgroff at apple.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Feb 25, 2016, at 2:40 PM, Radosław Pietruszewski <radexpl at gmail.com> wrote:
>>>>>> 
>>>>>> Ah, that’s a neat idea! Not sure it’s an improvement though to have a magic type that changes how the compiler treats your method, rather than a rather explicit *attribute* on the method…
>>>>> 
>>>>> There's no magic. If you can't construct a value of your return type, you can't return.
>>>>> 
>>>>> -Joe
>>>> 
>>>> 
>>>> The magic is somewhere else. Calling a @noreturn function allows you to do things you can’t otherwise do:
>>>> 
>>>> func foo() -> Int {
>>>> 	fatalError()
>>>> }
>>> 
>>> I see. The unreachable code check arguably ought to also accept this if fatalError returns any uninhabited type, since it'll never be able return if that's the case.
>>> 
>>> -Joe
>> 
>> Would that actually be useful today? (i.e. aside from your idea) To me, having a NoReturn return type seems more magic and less obvious than an attribute.
> 
> I admit I might be hopelessly in the language implementor's bubble here. From a semantic perspective, returning any uninhabited type (it doesn't need to be a specific one) feels less magic to me than having a special attribute or syntactic form for 'no return', since it achieves the desired semantics without additional language features. It also composes obviously with other aspects of function types like `throws` and currying (should we decide to add it back), whereas a special form needs to explicitly describe its interaction with those features.


This makes perfect sense to me:
func x() noreturn throws -> T

It could override a function that is not noreturn.

But it isn’t nearly common enough to warrant a qualifying keyword. Just from a language documentation perspective I would leave @noreturn as an attribute even though it’s technically part of the type.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/89e323ca/attachment.html>