> On Feb 23, 2017, at 11:41 AM, Anton Zhilin <[email protected]> wrote: > > 2017-02-23 20:09 GMT+03:00 Matthew Johnson <[email protected] > <mailto:[email protected]>>: > >> On Feb 23, 2017, at 10:58 AM, Anton Zhilin <[email protected] >> <mailto:[email protected]>> 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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
