[swift-evolution] guard let x = x

[Erica Sadun]

> On Nov 14, 2016, at 12:24 AM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Nov 11, 2016, at 2:48 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161114/e50aae86/attachment.html>