[swift-evolution] [Draft] Change @noreturn to unconstructible return type
L. Mihalkovic
laurent.mihalkovic at gmail.com
Sun Jun 5 15:16:44 CDT 2016
> On Jun 5, 2016, at 9:47 PM, Pyry Jahkola via swift-evolution <swift-evolution at swift.org> wrote:
>
>>>> I would prefer the type to be simple, and be implemented as a case-less enum (not a bottom value, as in Haskell).
>>>>
>>>> None should be a usual enum, with no compiler magic except that functions returning None are equivalent to current @noreturn.
>>>
>>> I think it would be more useful if the compiler allowed `Never` in every type context (i.e. whatever type `T` was expected, an expression of type `Never` would be allowed), making expressions like the following compile:
>>>
>>> let unwrapped: Int = optional ?? fatalError("explanation why this must not happen")
>>>
>>> — Pyry
>>
>> I dunno, I think @noreturn is clearer than any of these. It tells you that the function… won’t return. None, Never, etc. could be mistaken as a synonym for Void, whereas @noreturn is pretty hard to miss.
>
> FWIW, in the rejection of SE-0097, this was what the core team had to say about it:
>
> 1) For noreturn, the core team prefers to explore a solution where a function can be declared as returning an non-constructable “bottom” type (e.g. an enum with zero cases). This would lead to something like:
>
> func abort() -> NoReturn { … }
Interesting... There are other cases that would exist for which NoReturn seems the wrong name... but they knwo better I guess.
>
> This will require some new support in the compiler, but should flow better through the type system than @noreturn in function composition and other applications. Joe Groff offered to write a proposal for this.
>
> — Pyry
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160605/807e1565/attachment.html>
More information about the swift-evolution
mailing list