[swift-evolution] [Proposal] Typed throws
colin at springsandstruts.com
Tue Feb 21 18:42:03 CST 2017
On Sun, Feb 19, 2017 at 2:34 PM Anton Zhilin via swift-evolution <
swift-evolution at swift.org> 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
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
Secondly, rethrows allows a function with multiple throwing function
> parameters to become non-throwing iff all the arguments are non-throwing.
> How would you express it with generics?
> In the proposal, in this case you are required to provide a non-generic
> supertype of all used error types. This type can’t just turn into Never
> One solution would be to retain rethrows as an additional attribute.
> It would help with semantic information, and resulting error will be able
> to turn into Never as a special case—now that we know, that this function
> doesn’t throw that error itself.
> 2017-02-19 0:16 GMT+03:00 Martin Waitz <tali at admingilde.org>:
> Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution <
> swift-evolution at swift.org>:
> Thank you for taking the time to put this proposal together Anton! I
> really want to see typed throws make it into Swift 4. This will be a very
> nice feature to have.
> I noticed that you included Joe Groff’s idea of replacing `rethrows` by
> making every function have an error type which is by default `Never` for
> non-throwing functions and `Error` for throwing functions that do not
> specify an error type.
> I want to urge you to consider updating the proposal to take this
> direction now rather than later. This is a breaking change which means the
> longer we wait the harder it is to justify. In fact, I think incorporating
> the breaking change could increase the chances of it being accepted for
> Swift 4. Without that it is a purely additive change and those are not
> being given priority in the Swift 4 release.
> With typed throwing function parameters, it makes a lot of sense to be
> able to specify the rethrown type, based on the function given as parameter.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution