[swift-evolution] [Discussion] Analysis of the design of typed throws

[Matthew Johnson]

> On Feb 23, 2017, at 11:41 AM, Anton Zhilin <antonyzhilin at gmail.com> wrote:
> 
> 2017-02-23 20:09 GMT+03:00 Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>>:
> 
>> On Feb 23, 2017, at 10:58 AM, Anton Zhilin <antonyzhilin at gmail.com <mailto:antonyzhilin at gmail.com>> wrote:
>> 
>> See some inline response below.
>> Also, have you seen the issue I posted in Proposal thread? There is a way to create an instance of "any" type.
> 
> Yes, I saw that.  There is no problem with that at all.  As I point out in the analysis below, rethrowing functions are allowed to throw any error they want.  They are only limited by *where* they may throw.
> 
> OK, if a function throws on itself (which is an unusual situation), it will state its semantics in documentation, and it's the right place to do that.

I don’t understand what you mean here.

>> Yes, upcasting is only one way (besides others) to convert to a common error type. That's what I had in mind, but I'll state it more explicitly.
> 
> The important point is that if you include `rethrows` it should not place any restrictions on the type that it throws when its arguments throw.  All it does is prevent the function from throwing unless there is a dynamic guarantee that one of the arguments did in fact throw (which of course means if none of them can throw then the rethrowing function cannot throw either).
> 
> Yes, I understood that. 
>> Yes, any empty type should be allowed instead of just `Never`. That's a general solution to the ploblem with `rethrows` and multiple throwing parameters.
> 
> It looks like you clipped out the section "Why this solution is better” which showed how `rethrows` is not capable of correctly typing a function as non-throwing if it dynamically handles all of the errors thrown by its arguments.  What do you think of that?  In my opinion, it makes a strong case for eliminating rethrows and introducing the uninhabited type solution from the beginning.
> 
> I'm positive about baking removal of `rethrows` into the proposal.

Great!

> The specific example seems superficial to me. Usually we want to require the bare minimum from the caller. But here we require a proper error type, which is never used. Although, it may just be a convenience overload, and the other overload accepts `() -> Bool` or `() -> Void?`.

I don’t understand what you mean here.  In this alternative design *all* functions / closures / methods have an error type.  If one is not stated explicitly it defaults to `Never`.  If `throws` is specified without a type it defaults to `Error`.  There is no burden at all placed on callers.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170223/99630967/attachment.html>