This is largely unanswerable until that feature is actually designed. However, I can imaging wrapping an async-await in a Result to be easily passed around or transformed. Plus all of the usual non-asynchronous uses of Result in the first place.
Jon > On Nov 2, 2017, at 2:52 PM, Dan Stenmark <[email protected]> wrote: > > With the upcoming async-await constructs supporting do-try-catch natively, > what would the use-case for an explicit Result type be? > > Dan > >> On Nov 2, 2017, at 11:08 AM, Jon Shier via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Swift-Evolution: >> 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!) >> >> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md >> >> <https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md> >> >> >> Thanks, >> >> Jon Shier >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
