[swift-evolution] Adding Result to the Standard Library

[Chris Lattner]

> On Nov 6, 2017, at 4:13 AM, Jon Shier <jon at 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 good reasons for two possible designs:

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.

I don’t see any reason to add an arbitrary *list* of thrown types.  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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171108/633d7444/attachment.html>