[swift-evolution] [Pitch] Revamp Optional and Throws

[T.J. Usiyan]

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 at swift.org> wrote:

>
> On 2 May 2017, at 2:34 am, John McCall <rjmccall at apple.com> wrote:
>
>
> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170501/d28a1ea3/attachment.html>