<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 6, 2017, at 4:13 AM, Jon Shier <<a href="mailto:jon@jonshier.com" class="">jon@jonshier.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>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. </div></div></blockquote><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">1. Never add typed throws.</div><div class="">2. Add the ability to specify a single type thrown (typically an enum, but could be a struct), which defaults to Error if unspecified.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-Chris</div></div></body></html>