> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
