Key words: “if that is going to change” and I would add “even if it changes would all async use cases map to the new paradigm?”. I understand your concerns, but I am also wary of promised silver bullet solutions that promise or aim to take care of all use cases...
Sent from my iPhone > On 2 Nov 2017, at 18:48, Tony Allevato via swift-evolution > <[email protected]> wrote: > > > >> On Thu, Nov 2, 2017 at 11:32 AM Jon Shier <[email protected]> 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. > > This is one of the parts that concerns me, actually. The beauty of Swift's > error design is that function results denote expected/successful outcomes and > thrown errors denote unexpected/erroneous outcomes. Since they are different, > each is handled through its own language constructs, and since the language > itself supports it (rather than being entirely type-based), you don't have > the proliferation of unwrapping boilerplate that you have with Result<>. > > In our own code bases, I actively discourage the use of Result<> in that way, > because it tries to cram both of those concepts into the expected/successful > outcomes slot in the language. For asynchronous APIs that's somewhat > unavoidable today, but if that's going to change, I'd rather the language > focus on a way that's consistent with other error handling already present in > Swift. > > Adding an API to the standard library is the core team saying "this is > blessed as something around which we support APIs being designed." IMO, I'd > prefer it if the language did *not* bless two disparate ways of communicating > error outcomes but rather converged on one. > > IMO, "things aren't happening fast enough" isn't great motivation for putting > something permanently into the standard library or the language without > considering the context of other things going on around it. If you're going > to propose something that overlaps with asynchronous APIs, it only helps your > case if you can discuss how it can integrate—rather than collide—with those > efforts. > > > >> 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. >> >> >>> On Nov 2, 2017, at 2:26 PM, Tony Allevato <[email protected]> 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 >>>> <[email protected]> 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 <[email protected]> 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 >>>>>> <[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 >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jon Shier >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
