[swift-evolution] [Proposal] Typed throws

[Matthew Johnson]

> On Feb 19, 2017, at 2:16 PM, Anton Zhilin <antonyzhilin at gmail.com> wrote:
> 
> 2017-02-19 22:59 GMT+03:00 Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>>:
> 
> 
> 
>> On Feb 19, 2017, at 1:32 PM, Anton Zhilin <antonyzhilin at gmail.com <mailto:antonyzhilin at gmail.com>> wrote:
>> 
>> Now that I think about it, generic throws does not exactly cover rethrows.
>> Firstly, rethrows has semantic information that function itself does not throw—it would be lost.
>> 
> Can you elaborate further on what you mean by this?
> 
> 
> protocol Default { init() }
> 
> func exec(f: () throws -> Void) rethrows
> {
>     try f()
>     throw MyError()  // error because of rethrows
> }
> 
> func exec<E>(f: () throws(E) -> Void) throws(E)
>      where E: Error & Default
> {
>     try f()
>     throw E()  // okay
> }

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()`.  

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.

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/20170219/cea16877/attachment.html>