<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 14, 2016, at 12:24 AM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 11, 2016, at 2:48 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">To summarize:<br class=""><br class="">1. Swift needs to introduce a `Result` type.<span class="Apple-converted-space"> </span><br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Before we decide those, we can’t design Result.</span></div></div></blockquote></div><br class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">As a throw-away syntax to illustrate the idea:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let myResult = Result(of: try myThrowingCall()) //Any throwing call or block can become a Result</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>//Later… </div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>try unwrap myResult //This could even be in a different thread</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">The reason I am bringing this up now is that it may also affect our design of Unwrappable.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div></div></div></blockquote><br class=""></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" class="">https://gist.github.com/erica/3daa8ec77aef2feaefca3a3a19aedee3</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 class=""></div><div>* My original `if case`/`guard case` is here: <a href="https://github.com/apple/swift-evolution/pull/559" class="">https://github.com/apple/swift-evolution/pull/559</a></div><div><br class=""></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 class=""></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><div><br class=""></div><div>-- E</div><div><br class=""></div><br class=""></body></html>