[swift-evolution] Idea: change "@noreturn func f()" to "func f() noreturn"
Radosław Pietruszewski
radexpl at gmail.com
Thu Feb 25 16:40:11 CST 2016
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…
— Radek
> On 25 Feb 2016, at 23:12, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>
>>
>> On Feb 25, 2016, at 1:44 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> Premise: there are multiple ways of describing control-/data-flow when a function is called:
>>
>> func x() -> T // x returns a value, of type T, to the caller
>> func x() throws // x may throw an error to the caller
>> func x() throws -> T // x may throw an error, and also return a value
>> func x(...) rethrows ... // if a closure argument can throw an error, x may also throw
>> @noreturn func x() // x never returns to the caller
>>
>> "noreturn" is currently spelled as an attribute, but like "throws" / "rethrows" / "-> T", it's really describing how control flow works.
>>
>> IMO this calls for consistency: whatever happens "after" the function is called should appear "after" the parameter list.
>>
>> func x() noreturn {
>> ...
>> }
>>
>>
>> Thoughts?
>
> We really don't even need a special syntactic form or attribute for 'no return' at all. We could provide a standard unconstructible type:
>
> public /*closed*/ enum NoReturn {}
>
> and it would be impossible for a function that returns NoReturn to return normally.
>
> -Joe
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160225/9e4e6e54/attachment.html>
More information about the swift-evolution
mailing list