<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>You would continue to be free to discourage the usage of Result for whatever you want. For the rest of us, Result isn’t intended to replace throws or do/catch, but provide a way to accomplish things in a much more compact and sometimes natural way. As with any API it could be used stupidly. But frankly, what developers what to do to wrap their errors is up to them. Adding Result is just a way of blessing a result/error representation, since it has become a rather common pattern. If you’ve looked at the implementation I showed, you’ll see that there’s far more functionality than just a Result type, including API for converting back and forth from throwing functions, as well as functional transforms. Result is a complement to try do catch, not a replacement.<div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon<br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 2:48 PM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="">tony.allevato@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 2, 2017 at 11:32 AM Jon Shier <<a href="mailto:jon@jonshier.com" class="">jon@jonshier.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><span class="m_7577137149950176343Apple-tab-span" style="white-space:pre-wrap"> </span>That’s been an argument against Result for 2 years now. The usefulness of the type, even outside of whatever asynchronous language support the core team comes up with, perhaps this year, perhaps next year, is still very high. Even as something that just wraps throwing functions, or otherwise exists as a local, synchronous value, it’s still very useful as way to encapsulate the value/error pattern.</div></blockquote><div class=""><br class=""></div><div class="">This is one of the parts that concerns me, actually. The beauty of Swift's error design is that function results denote expected/successful outcomes and thrown errors denote unexpected/erroneous outcomes. Since they are different, each is handled through its own language constructs, and since the language itself supports it (rather than being entirely type-based), you don't have the proliferation of unwrapping boilerplate that you have with Result<>.</div><div class=""><br class=""></div><div class="">In our own code bases, I actively discourage the use of Result<> in that way, because it tries to cram both of those concepts into the expected/successful outcomes slot in the language. For asynchronous APIs that's somewhat unavoidable today, but if that's going to change, I'd rather the language focus on a way that's consistent with other error handling already present in Swift.</div><div class=""><br class=""></div><div class="">Adding an API to the standard library is the core team saying "this is blessed as something around which we support APIs being designed." IMO, I'd prefer it if the language did *not* bless two disparate ways of communicating error outcomes but rather converged on one.</div><div class=""><br class=""></div><div class="">IMO, "things aren't happening fast enough" isn't great motivation for putting something permanently into the standard library or the language without considering the context of other things going on around it. If you're going to propose something that overlaps with asynchronous APIs, it only helps your case if you can discuss how it can integrate—rather than collide—with those efforts.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">That pattern will likely never go away. Additionally, having the Result type in the standard library removes a source of conflict between all other Result implementations, which are becoming more common.</div><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 2:26 PM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" target="_blank" class="">tony.allevato@gmail.com</a>> wrote:</div><br class="m_7577137149950176343Apple-interchange-newline"><div class=""><div dir="ltr" class="">Given that the Swift team is currently working on laying the groundwork for asynchronous APIs using an async/await model, which would presumably tie the throwing cases more naturally into the language than what is possible using completion-closures today, are we sure that this wouldn't duplicate any efforts there or be made obsolete through other means?<div class=""><br class=""></div><div class="">In other words, while Result<> can be a very useful foundational component on its own, I think any proposal for it can't be made in isolation, but very much needs to consider other asynchronous work going on in the language.</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">You don’t lose it, it’s just behind `Error`. You can cast out whatever strong error type you need without having to bind an entire type to it generically. If getting a common error type out happens a lot, I usually add a convenience property to `Error` to do the cast for me. Plus, having to expose an entire new error wrapper is just a non starter for me and doesn’t seem necessary, given how Result is currently used in the community.<div class=""><br class=""></div><div class=""><br class=""></div><div class=""></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">Jon</div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 2:12 PM, Dave DeLong <<a href="mailto:swift@davedelong.com" target="_blank" class="">swift@davedelong.com</a>> wrote:</div><br class="m_7577137149950176343m_-350027757980587147Apple-interchange-newline"><div class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">I think I’d personally rather see this done with a generic error as well, like:</div><div class=""><br class=""></div><div class="">enum GenericResult<T, E: Error> {</div><div class=""><span class="m_7577137149950176343m_-350027757980587147Apple-tab-span" style="white-space:pre-wrap"> </span>case success(T)</div><div class=""><span class="m_7577137149950176343m_-350027757980587147Apple-tab-span" style="white-space:pre-wrap"> </span>case failure(E)</div><div class="">}</div><div class=""><br class=""></div>And a typealias:<div class=""><br class=""></div><div class="">typealias Result<T> = GenericResult<T, AnyError></div><div class=""><br class=""></div><div class="">This would require an “AnyError” type to type-erase a specific Error, but I’ve come across many situations where a strongly-typed error is <i class="">incredibly </i>useful, and I’d be reluctant to see that thrown away.</div><div class=""><br class=""></div><div class="">Dave<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_7577137149950176343m_-350027757980587147Apple-interchange-newline"><div class=""><div style="word-wrap:break-word;line-break:after-white-space" class="">Swift-Evolution:<div class=""><span class="m_7577137149950176343m_-350027757980587147Apple-tab-span" style="white-space:pre-wrap"> </span>I’ve written a first draft of a proposal to add Result<T> to the standard library by directly porting the Result<T> type used in Alamofire to the standard library. I’d be happy to implement it (type and tests for free!) if someone could point me to the right place to do so. I’m not including it directly in this email, since it includes the full implementation and is therefore quite long. (Discourse, please!) </div><div class=""><br class=""></div><div class=""><a href="https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md" target="_blank" class="">https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thanks, </div><div class=""><br class=""></div><div class="">Jon Shier</div><div class=""><br class=""></div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></blockquote></div></div>
</div></blockquote></div><br class=""></div></div></div></body></html>