<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2016, at 5:15 AM, Thomas Guthrie 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=""><div 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 <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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: "let a: Result<Foo> = 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 <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> (the 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. 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. For example, without typed throws you really just want the type to be Result<T>. With typed throws, can you still write that, or do you have to write Result<T, ErrorType>? Also, if we want every function result signature to have a corresponding Result<> type, does that permanently prevent us to supporting multiple error types with “typed throws”? 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 <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></div></div></blockquote><br class=""></div><div>Yeah, we extensively discussed adding a Result type internally, but ultimately couldn't justify it. The only real use case we could see in the wild was for threading errors through CPS-inversion-style abstractions like async promises, something we hope to provide proper language support for. More generally, expressing effects as monadic values is a pretty awful abstraction; aside from polluting the Internet with an endless deluge of unhelpful tutorials, they also don't compose cleanly, they impose nesting where is desired—you have to pick between Result<Async<T>> and Async<Result<T>>, or build ResultT<AsyncT<Identity>><T> out of monad transformers—and they don't do the natural thing when used with other higher-order abstractions—if you're mapping a `throws` function over a collection, you probably want to propagate that error like `rethrows` does, not end up with a collection of Result<T>. I'd rather see us adopt an extensible algebraic effects system, something like <a href="http://www.eff-lang.org" class="">http://www.eff-lang.org</a>, which provides a framework for `throws`, `async` and other control flow effects to be cleanly composed and abstracted over. I see `throws` as the first seed of that.</div><div><br class=""></div><div>-Joe</div></body></html>