On Mon, Nov 14, 2016 at 10:41 PM, Erica Sadun via swift-evolution < [email protected]> wrote:
> I believe that covers all the major points of this discussion. If so, I'm > going to table this until phase 2. I seem to recall another possibility that was brought up in this thread, which is currently absent from your document… Nevin On Mon, Nov 14, 2016 at 10:41 PM, Erica Sadun via swift-evolution < [email protected]> wrote: > > On Nov 14, 2016, at 12:24 AM, Jonathan Hull via swift-evolution < > [email protected]> wrote: > > > On Nov 11, 2016, at 2:48 PM, Chris Lattner <[email protected]> wrote: > > To summarize: > > 1. Swift needs to introduce a `Result` type. > > > Yes, but this is almost certainly a Swift 5 thing. We need to settle the > following arguments: > > 1) Does Result include async capabilities (I’m assuming we’ll get > something like async await + other higher level abstractions)? > > 2) Do we support typed error handling at some point (so you can write > “throws SpecificEnum”)? > > Before we decide those, we can’t design Result. > > > I wonder if Result will end up being a sub-protocol of Unwrappable (or > perhaps Unwrappable will give us everything we need for Result, with > Optional being an implementation which doesn’t allow an error state). > Basically, in addition to everything that we talked about with Unwrappable > there would be a sugared way to say “If you represent an error, throw it > now”. > > This way, Result basically becomes a way to record an error which can be > thrown at the time (and thread) of our choosing. It would make sense to > have symmetry here, so we would also want an easy way to take a throwing > call/block and turn it into a Result. In other words, most things can just > be designed with the current error handling model, with the throws becoming > Results for the transition across thread boundaries… and being turned back > into throws when you actually ‘try’ to use them. > > As a throw-away syntax to illustrate the idea: > > let myResult = Result(of: try myThrowingCall()) //Any throwing call or > block can become a Result > > //Later… > > try unwrap myResult //This could even be in a different thread > > > The reason I think we should have a protocol instead of a single generic > enum/struct is that there are complex cases which could still easily fit in > (or even add onto) that model if allowed. > > For a concrete example, in my packrat parser, I have several different > error states that can be handled differently. Some just cause it to fall > back to try the next rule, while others cause it to terminate parsing or > enter into a debug mode. I also have the concept of a semi-successful > return with errors (i.e. It is fully parsed, but instead of a result, the > parsed string is returned with a set of human-readable errors (+ locations > in the string) explaining why a result could not be returned). > > It would be nice for Result to be able to support that sort of thing as > well (at least as an add-on), and a protocol would give us the freedom to > extend the model as needed. > > The reason I am bringing this up now is that it may also affect our design > of Unwrappable. > > Thanks, > Jon > > > * Just so we have a record of this discussion for future refinement, I've > put this together: https://gist.github.com/erica/ > 3daa8ec77aef2feaefca3a3a19aedee3 > It addresses `Unwrappable` and `Result` but not `unwrap`. It does not > really touch on the async/threading aspects of `Result` and refers to the > design of `Result` as a matter for future discussion. > > * My original `if case`/`guard case` is here: https://github.com/ > apple/swift-evolution/pull/559 > > * I would write up the basic `unwrap` at some point, but it seems to me > that it would be heavily biased towards supporting `Unwrappable` so maybe I > should hold off until the ideas behind `Unwrappable` are better hashed out. > > I believe that covers all the major points of this discussion. If so, I'm > going to table this until phase 2. > > -- E > > > > _______________________________________________ > 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
