<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 6:19 PM, Dave DeLong <<a href="mailto:swift@davedelong.com" class="">swift@davedelong.com</a>> wrote:</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; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 6:11 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Proposing syntactic sugar for this at the same time would go a long way toward making me less reluctant to support it. As a type by itself, I don’t think it holds its weight in the standard library.<br class=""><br class="">The question that I’d want to see answered is, is it possible to make it so that these two functions are identical for all intents and purposes?<br class=""><br class="">func foo() throws -> Int<br class="">func foo() -> Result<Int><br class=""></div></blockquote><div class=""><br class=""></div><div class="">I mentioned this equivalency during the async/await debate: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039196.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039196.html</a></div><div class=""><br class=""></div><div class="">I think this would be a great addition.</div></div></div></div></blockquote><div><br class=""></div>Additionally, Erica had some thoughts around how to make unwrapping even easier, which includes support for Result<T>:</div><div><br class=""></div><div><a href="https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f" class="">https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f</a></div><div><br class=""></div><div>Dave</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br class="">Doing that at the call site is easy enough (the proposed implementation does much of that, but more could be done at the language level to remove the manual unwrapping), but I’m not sure how you reconcile the fact that, of those two declarations, an author *does* have to pick one to write.<br class=""><br class="">One thing I can think of off the top of my head is forbid functions from returning Result<> but allow them to be created by assignment from a throwing function. That, however, seems like an arbitrary and just flat out bizarre limitation and I can’t really bring myself to support it.<br class=""><br class="">I guess the problem I want to avoid is that, even if you sugar away all the differences between Result<> and throwing when it comes to *calling* these functions, there would still be two ways to declare essentially the same function, and the choice of which someone uses becomes arbitrary and meaningless.<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 2, 2017 at 5:02 PM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" 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 dir="ltr" class="">This is clearly a fine addition to the standard library; even Swift's Error Handling Rationale (<a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst</a>) mentions such an addition<br class=""><br class="">What separates standard library types from other types is that they have language level support, and the wrapping and unwrapping syntax here could definitely benefit from it (`.unwrap()`--which should be `.unwrapped()` incidentally--is so much less elegant in comparison to `?` and `!` for optionals (not that `Result` should use the exact such syntax for a distinct operation)). It would be a shame to transpose a third-party `Result` to the standard library without considering if any such tweaks would substantially improve ergonomics, interconversion with Optional and throws, etc.</div><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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="">Swift-Evolution:<div class=""><span class="m_4250095191961499738m_-4434525584991225668Apple-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><span class="m_4250095191961499738HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Jon Shier</div><div class=""><br class=""></div><div class=""><br class=""></div></font></span></div><br class="">_______________________________________________<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="">
<br class=""></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>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>