> 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] >> <mailto:[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 <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 <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
