[swift-evolution] guard let x = x

[Nevin Brackett-Rozinsky]

On Mon, Nov 14, 2016 at 10:41 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> 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 <
swift-evolution at swift.org> wrote:

>
> 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> 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
> 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/20161114/7b5bf71d/attachment.html>