I was thinking the same thing. Typed throws vs `Error` throws are the two major differences between different Result implementations, and they seem somewhat tied from a discussion perspective.
I agree with others here, I would like to see this added to the library, and I think it’s a generally valuable type that has broad uses beyond the completion handler solution that it’s commonly been used for. But if we add things to do the standard library, they need to be consistent, with the direction of Swift, and that’s a big call at this stage to either write in or out typed throws... Rod > On 3 Nov 2017, at 2:41 pm, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Nov 2, 2017, at 11:08 AM, 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 > > I’m generally supportive of this, but the design of such a thing forces > another contentious issue: whether the error handling model should be > extended to support "typed throws”. Without result, we can carry on pushing > the "typed throws” debate down the road. Adding it would force that issue to > be decided, which is complicated. > > -Chris > > > _______________________________________________ > 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
