> On Nov 2, 2017, at 6:19 PM, Dave DeLong <[email protected]> wrote: > > > >> On Nov 2, 2017, at 6:11 PM, Tony Allevato via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> 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. >> >> 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? >> >> func foo() throws -> Int >> func foo() -> Result<Int> > > I mentioned this equivalency during the async/await debate: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039196.html > > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039196.html> > > I think this would be a great addition.
Additionally, Erica had some thoughts around how to make unwrapping even easier, which includes support for Result<T>: https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f <https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f> Dave > >> >> 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. >> >> 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. >> >> 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. >> >> On Thu, Nov 2, 2017 at 5:02 PM Xiaodi Wu via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> This is clearly a fine addition to the standard library; even Swift's Error >> Handling Rationale >> (https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst >> <https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst>) >> mentions such an addition >> >> 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. >> >> >> >> On Thu, Nov 2, 2017 at 1:08 PM, 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 >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> 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
