> On Feb 23, 2017, at 12:30 PM, Anton Zhilin <antonyzhi...@gmail.com> wrote:
>
> 2017-02-23 21:01 GMT+03:00 Matthew Johnson <matt...@anandabits.com
> <mailto:matt...@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
