> On Nov 6, 2017, at 4:13 AM, Jon Shier <j...@jonshier.com
> <mailto:j...@jonshier.com>> wrote:
>
> This consideration is further complicated by the possible addition of
> typed throws in the future. However, the most commonly suggested
> implementation fo typed throws keeps the ability for throws to be untyped.
> Additionally, the feature usually allows multiple types to be thrown from a
> single function. Result<T> can handle all of these scenarios automatically,
> since it reduces all errors down to Error. A Result<T, E> however, would
> either lose the ability to encapsulate any function with multiple error
> types, or otherwise have to wrap those cases in something like AnyError, in
> additional to having to do so in the untyped case.
As I mentioned up-thread, this proposal isn’t going to go anywhere without a
proper discussion of typed throws. There are two possible designs that have
strong rationale:
1. Never add typed throws.
2. Add the ability to specify a single type thrown (typically an enum, but
could be a struct), which defaults to Error if unspecified.
In contrast, I don’t see any reason to add an arbitrary *list* of thrown types,
and I can’t imagine such a design happening. Swift already has ways to specify
alternatives (enums) and this would encourage exactly the behavior from APIs
that we want to avoid.
This choice between 1/2 needs to be decided before introducing result, because
#1 means it should be Result<T>, and #2 means it should be Result<T,E>. If this
is important to you, I’d suggest starting a dedicated discussion thread about
the topic.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
