[swift-evolution] [Discussion] Analysis of the design of typed throws
antonyzhilin at gmail.com
Thu Feb 23 11:41:56 CST 2017
2017-02-23 20:09 GMT+03:00 Matthew Johnson <matthew at anandabits.com>:
> On Feb 23, 2017, at 10:58 AM, Anton Zhilin <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.
> 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
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
> 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.
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?`.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution