> On Feb 22, 2017, at 7:10 AM, Anton Zhilin <[email protected]> wrote: > > How about this: > > func bypassRethrows<E: Error>(_ f: () throws(E) -> ()) throws(E) { > if let e = (MyError() as Error) as? E { > throw e > } > } > I obviously can’t “test” this right now, but should work? > >
No because there are many types that conform to `Error` but are not `E` and the signature says you only throw `E`. You have no way to get an instance of `E` except by catching one thrown by `f` because `Error` does not have any initializers and you don’t have any visibility to anything that provides an `E` in any way except when `f` throws. I am hoping to have time to write up my analysis of generic rethrowing functions later today. There are some very interesting tradeoffs we need to make. > 2017-02-22 3:42 GMT+03:00 Colin Barrett <[email protected] > <mailto:[email protected]>>: > > > > On Sun, Feb 19, 2017 at 2:34 PM Anton Zhilin via swift-evolution > <[email protected] <mailto:[email protected]>> 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. > > That's not true. Parametric polymorphism guarantees that rethrows and > polymorphic throw are the same. > > For example, you can prove that as a consequence of parametricity that there > is only one (pure) function in the of the set of all functions with the type > ``forall A. A -> A'' and furthermore that it is the identity function. > > The intuition behind this is that you (meaning the fiction; imagine being a > function!) cannot construct your own value of "A" since you don't have any > information about what "A" is. The only place to get an "A" is from your > argument. > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
