+1 from me… for what it's worth. The value, in my opinion, is that we won't each have to add result. I would prefer Either<A,B> but I will take Result<A>.
On Thu, Nov 2, 2017 at 2:35 PM, Dave DeLong via swift-evolution < swift-evolution@swift.org> wrote: > > On Nov 2, 2017, at 12:32 PM, Jon Shier <j...@jonshier.com> wrote: > > That’s been an argument against Result for 2 years now. The usefulness of > the type, even outside of whatever asynchronous language support the core > team comes up with, perhaps this year, perhaps next year, is still very > high. Even as something that just wraps throwing functions, or otherwise > exists as a local, synchronous value, it’s still very useful as way to > encapsulate the value/error pattern. That pattern will likely never go > away. Additionally, having the Result type in the standard library removes > a source of conflict between all other Result implementations, which are > becoming more common. > > > 👆 👏 > > There’s a lot of stuff I’m tired of implementing myself while waiting for > the the core team “to lay the ground for”. Result is up there near the top > of my list too. > > Dave > > > > On Nov 2, 2017, at 2:26 PM, Tony Allevato <tony.allev...@gmail.com> wrote: > > Given that the Swift team is currently working on laying the groundwork > for asynchronous APIs using an async/await model, which would presumably > tie the throwing cases more naturally into the language than what is > possible using completion-closures today, are we sure that this wouldn't > duplicate any efforts there or be made obsolete through other means? > > In other words, while Result<> can be a very useful foundational component > on its own, I think any proposal for it can't be made in isolation, but > very much needs to consider other asynchronous work going on in the > language. > > > On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution < > swift-evolution@swift.org> wrote: > >> You don’t lose it, it’s just behind `Error`. You can cast out whatever >> strong error type you need without having to bind an entire type to it >> generically. If getting a common error type out happens a lot, I usually >> add a convenience property to `Error` to do the cast for me. Plus, having >> to expose an entire new error wrapper is just a non starter for me and >> doesn’t seem necessary, given how Result is currently used in the community. >> >> >> Jon >> >> >> On Nov 2, 2017, at 2:12 PM, Dave DeLong <sw...@davedelong.com> wrote: >> >> I think I’d personally rather see this done with a generic error as well, >> like: >> >> enum GenericResult<T, E: Error> { >> case success(T) >> case failure(E) >> } >> >> And a typealias: >> >> typealias Result<T> = GenericResult<T, AnyError> >> >> This would require an “AnyError” type to type-erase a specific Error, but >> I’ve come across many situations where a strongly-typed error is *incredibly >> *useful, and I’d be reluctant to see that thrown away. >> >> Dave >> >> On Nov 2, 2017, at 12: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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution