> On Nov 2, 2017, at 6:11 PM, Tony Allevato via swift-evolution > <swift-evolution@swift.org> 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. 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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
