<div dir="ltr">On Thu, Nov 2, 2017 at 7:11 PM, Tony Allevato <span dir="ltr"><<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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><br>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><br>func foo() throws -> Int<br>func foo() -> Result<Int><br><br>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></blockquote><div><br></div><div>Agree, issues such as this *must* be addressed for a successful `Result` proposal. The resulting design should be highly coherent and reflect a unitary vision of error handling; it cannot be merely a bolting-on of an external Result type.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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><br>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.<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 2, 2017 at 5:02 PM Xiaodi Wu 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 dir="ltr">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">https://github.com/apple/<wbr>swift/blob/master/docs/<wbr>ErrorHandlingRationale.rst</a>) mentions such an addition<br><br>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"><br><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier 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">Swift-Evolution:<div><span class="m_619999757972946007m_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><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><span class="m_619999757972946007m_4250095191961499738HOEnZb"><font color="#888888"><div><br></div><div>Jon Shier</div><div><br></div><div><br></div></font></span></div><br>______________________________<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>
<br></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></div></blockquote></div><br></div></div>