On 7 Jun, 2016, at 13:46, Thorsten Seitz <[email protected]> wrote: >> Am 07.06.2016 um 20:11 schrieb Damien Sorresso via swift-evolution >> <[email protected]>: >> >> On 7 Jun, 2016, at 09:47, Brent Royal-Gordon via swift-evolution >> <[email protected]> wrote: >>>> I disagree. We are discussing how to annotate a function in some way so >>>> that the compiler knows that the code following it will never be executed >>>> *and* so a human who reads the declaration knows that it does not return. >>>> “Never" is a poor choice for that. Never what? Never return? Never use >>>> this function? Never say never again? >>> >>> "Never return". That's why it's in the return type slot, right after the >>> `->`. If you read it out loud, you'll read "returns Never", which is >>> exactly correct. >> >> A return type makes a lot of sense linguistically but does not cover all >> practical cases because you might not be the one deciding what the >> function's signature is. For example, you might implement a protocol method >> that is non-optional, but you never expect to be called. The only way to >> indicate that to the compiler is with an attribute. >> -damien > > That would be lying to the type system like Java did in their collection > library throwing exceptions for some method implementations which is horribly > broken. > If you conform to a protocol that means you sign a contract that all the > methods of the protocol may be called. There is no way out. > Except in cases with type parameters (or associated types in protocols) where > you might use Never for such a type parameter, thereby making all methods > taking arguments of this type uncallable without cheating the type system, > e.g.
In this scenario, the protocol has been defined in a sub-optimal way that is
outside the bounds of your control. I'm totally sympathetic to the argument
that it's wrong, but it does happen, so I am sympathetic to API clients who
want to do as much of the right thing as possible while also registering their
displeasure via an attribute.
-damien
> // quick and dirty example without method bodies and not to be taken too
> seriously
>
> protocol QueueType {
> associatedtype In
> associatedtype Out
> func enqueue(element: In)
> func dequeue() -> Out
> }
>
> struct Queue<In, Out> : QueueType {
> func enqueue(element: In)
> func dequeue() -> Out
> }
>
> struct Source<Out> : QueueType {
> func enqueue(element: Never)
> func dequeue() -> Out
> }
>
> struct Sink<In> : QueueType {
> func enqueue(element: In)
> func dequeue() -> Never
> }
>
> let source: Source<Int> = ...
> let sink: Sink<String> = ...
> let queue: Queue<Int, String> = ...
> queue.enqueue(source.dequeue())
> sink.enqueue(queue.dequeue())
> source.enqueue(1) // type error
>
> -Thorsten
>
>
>
>
>
>>
>>> NoReturn, on the other hand, does *not* read well in that slot: "returns
>>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes
>>> no sense whatsoever *as a type name*.
>>>
>>>> If you want bottom types for other uses, give them their own appropriate
>>>> and self documenting names.
>>>
>>> The problem is, types flow through the type system. Use a NoReturn method
>>> with optional chaining, now you have an Optional<NoReturn>. flatMap over
>>> that Optional<NoReturn>, now you have a parameter of type NoReturn. What's
>>> a *parameter* of type NoReturn? You'd want it to be, say, a different
>>> bottom type named NoPass, but you can't—the type came from a NoReturn, and
>>> it's stuck being a NoReturn.
>>>
>>> Never works pretty well—honestly, surprisingly well—in all of these
>>> contexts. The method returns Never, so optional chaining gives you an
>>> Optional<Never>, so flatMap has a Never parameter. I have yet to discover a
>>> case where it isn't easily interpreted to mean exactly what it really does
>>> mean.
>>>
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>>
>>> _______________________________________________
>>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
