> On Feb 19, 2017, at 2:16 PM, Anton Zhilin <antonyzhi...@gmail.com> wrote: > > 2017-02-19 22:59 GMT+03:00 Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>>: > > > >> On Feb 19, 2017, at 1:32 PM, Anton Zhilin <antonyzhi...@gmail.com >> <mailto:antonyzhi...@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).
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
