<div dir="ltr"><div class="gmail_extra">Thanks for the feedback, Stephen.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 1:03 PM, Stephen Celis <span dir="ltr"><<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> On Feb 29, 2016, at 3:09 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><span>><br>
> - If Swift's error-handling mechanisms evolved into a first-class Result type, would this proposal be moot?<br>
<br>
</span>Could you clarify what you mean by this?<br></blockquote><div><br></div><div>I didn't think through it very far, which is why I put it under "discussion topics" rather than fleshing it out :-)</div><div><br></div><div>I guess I'm just wondering whether the syntax for optionals/errors might change significantly enough with the introduction of Result that it wouldn't make sense to introduce this feature now.</div><div><br></div><div>Suppose we had "enum Result<T> { case Some(T), Error(ErrorType) }". Then "throws" might be syntactic sugar: "foo() throws -> T" would be the same as "foo() -> Result<T>". Using today's syntax, you could handle Results using switch:</div><div><br></div><div> switch foo() {</div><div> case .Some(let x):</div><div> // use x</div><div> case .Error(let error):</div><div> // use error<br> }</div><div><br></div><div>But conceivably the Result would be treated with more first-class syntax:</div><div><br></div><div> if let x = try foo() {</div><div> // handle .Some</div><div> } catch {</div><div> // handle .Error</div><div> }</div><div><br></div><div>The more I think about this, it doesn't seem too different from what I proposed, so I guess it's not worth worrying about conflicts.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
> - Would this make sense as a feature of pattern-matching, rather than just "guard", so you could also do "if case let x = try foo() { ... } catch { ... }" ?<br>
<br>
</span>This makes sense to me at first glance, though it makes things rather complicated.<br>
<br>
- Can `catch` blocks appear before `else [if]` blocks? E.g.,<br>
<br>
if try test() != nil {<br>
...<br>
} catch {<br>
...<br>
} else if try test2() != nil {<br>
...<br>
} else {<br>
...<br>
} catch {<br>
...<br>
}<br></blockquote><div><br></div><div>That's an interesting point. I can't see why this shouldn't be allowed. Would you be able to handle all errors at the end?</div><div><br></div><div> e.g.: if case let x = try foo() { ... } else if case let y = try bar() { ... } catch { /*handle errors from both expressions*/ }</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- Are `if`/`else` blocks generally promoted to `do`-like state when `catch` blocks exist?<br>
<br>
if something() {<br>
try failable()<br>
} catch {<br>
...<br>
}<br></blockquote><div><br></div><div>Hmm. I think I would like this, but there may have been reasons for not allowing this sort of thing. I can't recall if it's been discussed before. What do others think?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- Does this extend to `switch` and how?<br></blockquote><div><br></div><div>Maybe just the same thing: "switch try foo() { ... } catch { ... }" ?</div></div></div></div>