[swift-evolution] [Proposal] Typed throws

[Anton Zhilin]

2017-02-19 23:29 GMT+03:00 Matthew Johnson <matthew at 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, 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.

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.
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).
>
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/21347349/attachment.html>