I think that `Either` in the standard library with some means to provide generalized behavior for two-cased enums would be an amazing salve for this. Handling errors thrown in Playgrounds is one of the best examples, in my opinion, of why we need something like Either/Result in the standard library. It is fairly unpleasant to work with throwing code in a playground. I end up creating a `Result` type to standardize and sweeten throwing, for one.
On Mon, May 1, 2017 at 5:48 PM, Rod Brown via swift-evolution < swift-evolution@swift.org> wrote: > > On 2 May 2017, at 2:34 am, John McCall <rjmcc...@apple.com> wrote: > > > On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution < > swift-evolution@swift.org> wrote: > I agree that the key problem with the current architecture that you're > alluding to is it can't be easily *stored and transferred. *Swift errors > are great for live action but holding and passing after the throwing event > is problematic, and this is an elegant solution. The storage issue is > when holding it as a property, and the transferring issue is when passing > it to a closure as a results of an asynchronous operation etc. These are > both definitely cases where storage of the type-or-error makes perfect > sense. > > I think the key problem getting this accepted by the Swift Team will be > that it doesn't currently have any specific use in the standard library. As > a low level set of types, errors are generated by the lower levels but > rarely stored, so the Standard library doesn't need the storage. Generally > the only place we have to do that is in end user code. And currently the > standard library doesn't have to support asynchronous operations natively, > so there's nothing inside the kit that would require it to do completion > handlers with errors. > > > We've definitely considered including a Result type, but our sense was > that in an ideal world almost no code would be using it. It's hard to > imagine an ordinary API that ought to be returning a Result rather than > throwing, and once you've defined that away, the major remaining use case > is just to shift computation around, like with a completion handler. That > explicit computation-shifting pattern is something we're hoping to largely > define away with something like C#'s async/await, which would leave Result > as mostly just an implementation detail of such APIs. We didn't want to > spend a great deal of time designing a type that would end up being so > marginal, especially if the changing role would lead us into different > directions on the design itself. We also didn't want to design a type that > would become an obstacle to potential future language changes like, say, > typed throws. > > The downside, of course, is that as long as we lack that async/await > design, computation-shifting isn't real great. > > John. > > > This makes sense and is sensible. I’m curious how such an API would play > with the existing NSURLSession completion handlers and the like, but I’m > sure the community can design something appropriate. > > I think the only remaining case is simply storing a result-or-error for > later handling, storage to disk, etc. I agree with your contention that the > vast majority of the use case for this type is for computation shifting. I > think it would and should be rare that we would want to “store” as a > variable the “result-or-error” type. Errors should be handled at runtime in > the vast majority of cases, presented to the user or otherwise handled, and > then moved on from, with the reason no longer being relevant. > > As you say, in the meantime, it does leave computation-shifting a bit > ad-hoc and convoluted, but I think the community has standardized on the > Result temporary solution. > > > > This would therefore be an element in the standard library purely so we > don't have 50,000 different libraries with 50,000 different result types. > I'd love to see this standardised so frameworks were more compatible. I'm > just not sure whether the Core Team would see it as pressing to try and > officiate a certain type that they themselves don't use. > > > > _______________________________________________ > 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