[swift-evolution] [Discussion] Analysis of the design of typed throws

[Matthew Johnson]

> On Feb 23, 2017, at 12:30 PM, Anton Zhilin <antonyzhilin at gmail.com> wrote:
> 
> 2017-02-23 21:01 GMT+03:00 Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>>:
> I don’t understand what you mean here.
> 
> I was a bit confused. Thanks to your clarification, I discovered that `rethrows` functions currently can use `throw` expression, but only in `catch` scope, which handles error handling for one of function parameters.
> In my view, this language feature should be removed without replacement if we remove `rethrows`. Instead, we should always be able to throw error type stated in `throws(...)`.

I agree with this as long as all functions with an uninhabitable error type are treated as non-throwing.

> 
> I don’t understand what you mean here.  In this alternative design *all* functions / closures / methods have an error type.  If one is not stated explicitly it defaults to `Never`.  If `throws` is specified without a type it defaults to `Error`.  There is no burden at all placed on callers.
> 
> I meant that in that specific case I would prefer returning an optional. If error value is not meaningful--and that is the case with `f` function parameter and corresponding `F` error type--then we are dealing with simple domain errors, which are expressed with returning optionals instead of throwing. I'll include this example anyway.

You would still be able to return an Optional with no trouble.  It would have an implicit error type of `Never` and a return type of `Optional`.  This would be treated as a non-throwing function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170223/43ec2d85/attachment.html>