<div dir="ltr">+1 from me… for what it's worth. The value, in my opinion, is that we won't each have to add result. I would prefer Either<A,B> but I will take Result<A>.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 2, 2017 at 2:35 PM, Dave DeLong via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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"><br><div><span class=""><blockquote type="cite"><div>On Nov 2, 2017, at 12:32 PM, Jon Shier <<a href="mailto:jon@jonshier.com" target="_blank">jon@jonshier.com</a>> wrote:</div><br class="m_6899550497664357608Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><span class="m_6899550497664357608Apple-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. 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.<br></div></div></blockquote><div><br></div></span><div>👆 👏 </div><div><br></div><div>There’s a lot of stuff I’m tired of implementing myself while waiting for the the core team “to lay the ground for”. Result is up there near the top of my list too.</div><div><div class="h5"><div><br></div><div>Dave</div><div><br></div><br><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>On Nov 2, 2017, at 2:26 PM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>> wrote:</div><br class="m_6899550497664357608Apple-interchange-newline"><div><div dir="ltr">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><br></div><div>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><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></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">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><br></div><div><br></div><div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>Jon</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><div><br><blockquote type="cite"><div>On Nov 2, 2017, at 2:12 PM, Dave DeLong <<a href="mailto:swift@davedelong.com" target="_blank">swift@davedelong.com</a>> wrote:</div><br class="m_6899550497664357608m_-350027757980587147Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><div>I think I’d personally rather see this done with a generic error as well, like:</div><div><br></div><div>enum GenericResult<T, E: Error> {</div><div><span class="m_6899550497664357608m_-350027757980587147Apple-tab-span" style="white-space:pre-wrap"> </span>case success(T)</div><div><span class="m_6899550497664357608m_-350027757980587147Apple-tab-span" style="white-space:pre-wrap"> </span>case failure(E)</div><div>}</div><div><br></div>And a typealias:<div><br></div><div>typealias Result<T> = GenericResult<T, AnyError></div><div><br></div><div>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>incredibly </i>useful, and I’d be reluctant to see that thrown away.</div><div><br></div><div>Dave<br><div><br><blockquote type="cite"><div>On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_6899550497664357608m_-350027757980587147Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">Swift-Evolution:<div><span class="m_6899550497664357608m_-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><br></div><div><a href="https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md" target="_blank">https://github.com/jshier/<wbr>swift-evolution/blob/master/<wbr>proposals/0187-add-result-to-<wbr>the-standard-library.md</a></div><div><br></div><div><br></div><div>Thanks, </div><div><br></div><div>Jon Shier</div><div><br></div><div><br></div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div></div></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>