Just want to say this proposal is absolutely amazing and I can't wait for it to land!
I'd also want to add my vote for the throws MyError -> Void syntax over the use throws(MyError) or throws<MyError>
This proposal was accepted in December and has been available in the nightly toolchains for a few months (with parentheses, for the reasons I mentioned in the acceptance).
3 Likes
With the introduction of typed throws, is it possible to handle two call backs properly? for example:
func foo<E1: Error, E2: Error>(handler1: () throws(E1) -> Void, handler2: () throws(E2) -> Void) throws {
handler1()
handler2()
}
When handler1 and handler2 don't throw, it seems I still need to put a try before foo, as the returning value is inferred (and explicitly annotated) to be any Error.
Is there a way to change this so that it would only throw when at least one of its handlers throws?
2 Likes
In the absence of sum types (or equivalent functionality for specifying a union of error types to [re]throw), I don't think this case is supported, unfortunately. 
Of course, you could keep the typing on the inputs (the closure parameters) while using rethrows on the output (the function itself). You lose the type information, but you at least get the behaviour you want re. omitting try.
(or at least, I assume - I don't specifically recall if rethrows handles multiple throwing closure parameters)
I don't think it's possible in today's Swift, but with language evolution a limited form could be possible in the future even without sum types if errorUnion(E1, E2) from the proposal was turned into a proper type expression.
It was discussed around here: [Pitch] Typed throws in the Concurrency module - #28 by Douglas_Gregor
1 Like