<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On 14 Mar 2016, at 11:36, Ondrej Barina via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class="">it would be great usage of Result. (there was discussion about it. I<br class="">think it was rejected).<br class=""><br class="">Not really sure about: &nbsp;"let a: Result&lt;Foo&gt; = makeFoo(42)"<br class="">I can see that this could become more needed/used when we are going<br class="">towards async coding in next Swift (4.0?).<br class=""></blockquote><br class="">Result is mentioned in&nbsp;<a href="https://github.com/apple/swift/blob/master/docs/ErrorHandling.rst#manual-propagation-and-manipulation-of-errors" class="">https://github.com/apple/swift/blob/master/docs/ErrorHandling.rst#manual-propagation-and-manipulation-of-errors</a>&nbsp;(the&nbsp;proposal/doc for swift’s current error handling) and John McCall had this to say about it:<div class=""><br class=""><blockquote type="cite" class=""><div class="">We considered it, had some specifics worked out, and then decided to put it on hold. &nbsp;Part of our reasoning was that it seemed more like an implementation detail of the async / CPS-conversion features we’d like to provide than an independently valuable feature, given that we don’t want to encourage people to write library interfaces using functional-style error handling instead of throws.</div><div class=""><br class=""></div><div class="">It’s also a feature that’s directly affected by the design of typed throws, which in turn poses some usability challenges for it. &nbsp;For example, without typed throws you really just want the type to be Result&lt;T&gt;. &nbsp;With typed throws, can you still write that, or do you have to write Result&lt;T, ErrorType&gt;? &nbsp;Also, if we want every function result signature to have a corresponding Result&lt;&gt; type, does that permanently prevent us to supporting multiple error types with “typed throws”? &nbsp;Also, would it be too frustrating to work with typed Result values if we don’t allow implicit covariant conversions along one or both dimensions?</div></blockquote><br class="">(From&nbsp;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001433.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001433.html</a>)</div></body></html>