[swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[L. Mihalkovic]

Although i understand the intention, there are existing designs in other languages offering proven better alternatives. So i would not leave thinking that a compelling case for 'Never' has been made.

> On Jun 24, 2016, at 6:01 PM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-
> noreturn-bottom-type.md
> 
> I can think of at least one example of using Never.
> Suppose Stream protocol that returns a value at the end:
> 
> protocol Stream {
>    associatedtype Element
>    associatedtype Result
> 
>    mutable func next() -> Either<Element, Result>
> }
> 
> Result can be used for information why the stream has stopped.
> Calling next() after it returns Result is undefined behaviour.
> 
> You can easily see that Iterator is a special case of Stream
> with Result = ().
> 
> Algorithms on IteratorWithResult should not drop the result:
> 
> func forEach<S>(stream: inout S,
>                block: (S.Element) -> ())
>                -> S.Result
>                where S: Stream
> 
> We can split our Stream nicely:
> 
> func split<S>(stream: inout S,
>              take: Int)
>              -> TakePrefixStream
>              where S: Stream
> 
> TakePrefixStream.Result is also a Stream, so to process two parts of 
> stream differently, we do:
> 
> split(s, take: 10).forEach(calledOnFirstTen).forEach(calledOnOthers)
> 
> In the same spirit, we can split a stream into 3 or N parts.
> Note that split itself does not take any elements from the Stream,
> everything is lazy.
> 
> You've already noticed where Never has its place.
> If a stream is infinite, we use Result = Never.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution