On Thu, Nov 2, 2017 at 7:11 PM, Tony Allevato <tony.allev...@gmail.com> 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> > > 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. > Agree, issues such as this *must* be addressed for a successful `Result` proposal. The resulting design should be highly coherent and reflect a unitary vision of error handling; it cannot be merely a bolting-on of an external Result type. > 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> 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) 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> 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 >>> >>> >>> Thanks, >>> >>> Jon Shier >>> >>> >>> >>> _______________________________________________ >>> 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 >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution