<div dir="ltr">On Mon, Nov 14, 2016 at 10:41 PM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I believe that covers all the major points of this discussion. If so, I'm going to table this until phase 2.</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">I seem to recall another possibility that was brought up in this thread, which is currently absent from your document…</div><div class="gmail_extra"><br></div><div class="gmail_extra">Nevin</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 14, 2016 at 10:41 PM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="gmail-h5"><br><div><blockquote type="cite"><div>On Nov 14, 2016, at 12:24 AM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail-m_1913763620450914877Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Nov 11, 2016, at 2:48 PM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:</div><br class="gmail-m_1913763620450914877Apple-interchange-newline"><div><div><blockquote type="cite" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">To summarize:<br><br>1. Swift needs to introduce a `Result` type.<span class="gmail-m_1913763620450914877Apple-converted-space"> </span><br></blockquote><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Yes, but this is almost certainly a Swift 5 thing. We need to settle the following arguments:</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">1) Does Result include async capabilities (I’m assuming we’ll get something like async await + other higher level abstractions)?</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">2) Do we support typed error handling at some point (so you can write “throws SpecificEnum”)?</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Before we decide those, we can’t design Result.</span></div></div></blockquote></div><br><div>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”. </div><div><br></div><div>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.</div><div><br></div><div>As a throw-away syntax to illustrate the idea:</div><div><br></div><div><span class="gmail-m_1913763620450914877Apple-tab-span" style="white-space:pre-wrap"> </span>let myResult = Result(of: try myThrowingCall()) //Any throwing call or block can become a Result</div><div><br></div><div><span class="gmail-m_1913763620450914877Apple-tab-span" style="white-space:pre-wrap"> </span>//Later… </div><div><br></div><div><span class="gmail-m_1913763620450914877Apple-tab-span" style="white-space:pre-wrap"> </span>try unwrap myResult //This could even be in a different thread</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>The reason I am bringing this up now is that it may also affect our design of Unwrappable.</div><div><br></div><div>Thanks,</div><div>Jon</div></div></div></blockquote><br></div></div></div><div>* Just so we have a record of this discussion for future refinement, I've put this together: <a href="https://gist.github.com/erica/3daa8ec77aef2feaefca3a3a19aedee3" target="_blank">https://gist.github.<wbr>com/erica/<wbr>3daa8ec77aef2feaefca3a3a19aede<wbr>e3</a></div><div>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.</div><div><br></div><div>* My original `if case`/`guard case` is here: <a href="https://github.com/apple/swift-evolution/pull/559" target="_blank">https://github.com/<wbr>apple/swift-evolution/pull/559</a></div><div><br></div><div>* 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.</div><div><br></div><div>I believe that covers all the major points of this discussion. If so, I'm going to table this until phase 2.</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>-- E</div><div><br></div><br></font></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>