> On Jun 5, 2016, at 9:47 PM, Pyry Jahkola via swift-evolution 
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to