> On Feb 20, 2017, at 3:58 AM, Anton Zhilin <antonyzhi...@gmail.com> wrote: > > 2017-02-19 23:29 GMT+03:00 Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>>: > > > > Thanks. There is nothing wrong with this at all. Your second `exec` would > not accept a non-throwing function because `Never` cannot conform to > `Default`. If it didn’t include the `Default` constraint it would not be > able to `throw E()`. > > > But that raises another concern. In a previous discussion, it was taken for > granted that Never should conform to all protocols > Do you have a pointer to this discussion? I must have missed it.
> , because if one obtains an instance of Never (and they won’t), then > everything is possible. But now we say that Never can’t conform to Default, > because this would break its very invariant. Also it can’t conform to any > protocol with static members or initializers. > > It seems highly problematic to me to say that never conforms to any protocol with non-instance requirements. > But then basically, Never trick can’t be used when we request anything more > than Error from generic error type (with static members or initializers). So > this approach turns out to be more limiting than rethrows. > Can you elaborate here? If you require a function to throw an error type that has non-instance requirements then you would necessarily be restricting callers to provide a throwing function. It is not possible to express such a function with `rethrows`. You can’t talk about the error type at all. If you could talk about the error type and were able to constrain it in this way `rethrows` would necessarily have to exhibit the same behavior as the generic version. The behavior arises out of the constraint you are applying, not the mechanism by which you forward the type. > Don’t misunderstand me—I love the idea of Never replacing rethrows. Just want > to make sure we don’t lose anything important by the way. > > > > > If you remove the `Default` constraint and change `throws(E)` to `throws`, > and throw `MyError()` in place of `E()` in both places then it behaves > exactly as the first example. We don’t lose any expressivity at all. > > This is actually an example of a strength of Joe’s suggestion: the second > `exec` is able to throw an error of a type that matches the error that might > be thrown by the calling argument `f`. I’m not sure of where this might be > useful but it is definitely not possible with `rethrows` while it is possible > with Joe’s proposal. We have more flexibility in API design under Joe’s > proposal. > > > Nice. Whether we can throw the error ourselves depends on our ability to > create the error. > > > > You did make a great point about coalescing error types from several > different function arguments. That’s an edge case, but the inability to > coalesce is indeed a problem that probably needs to be addressed by the typed > throws proposal in one way or another (if we don’t go with Joe’s suggestion > we would need to specify how `rethrows` behaves in cases like this in some > detail). > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
