<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><blockquote type="cite" class=""><div class="">Le 9 nov. 2017 à 08:57, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div 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></div></div></blockquote><br class=""></div><div>Hello,</div><div><br class=""></div><div>I wish that the Swift-Evolution discussion around typed / untyped throws would avoid three traps:</div><div><br class=""></div><div>- a bloodshed between pro and anti typed-throws</div><div>- a pro-typed-throws echo chamber (since untyped throws is the passive status quo, and typed throws the energetic challenger)</div><div>- even less average-joe-programmers than ever (on a topic that immensely impacts their everyday job)</div><div><br class=""></div><div>Shouldn't the community elect a benevolent dictator that would settle this subject? The final choice has of course to be sensible, but also strong and sharp.</div><div><br class=""></div><div>Gwendal</div><div><br class=""></div></body></html>