<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>How about only allowing "guard try? catch":</div><div><br></div><div> guard let x = try? foo() catch { ... }</div><div><br></div><div>This would address both concerns of Chris:</div><div><br></div><div>• "<span style="background-color: rgba(255, 255, 255, 0);">This is inconsistent with what we currently have, because “if let” and “guard let” match against an optional and succeed iff the optional is present."</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">• "This shouldn’t be tied to the presence of try, because it already means something (that the enclosed expression can throw). This:</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> guard let x = try foo() …</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Already means “call foo, if it throws, propagate the error. If not, test the returned optional”."</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">With "try?" it is clear that "foo()" doesn't throw an error in the guard expression and guard matches against an optional. This makes it unambiguous to "guard try else" which throws in this case.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Kind regards</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">- Maximilian</span></div><div><br>Am 10.03.2016 um 05:32 schrieb Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 8, 2016, at 11:37 AM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thanks for the feedback, Chris.<div class=""><br class=""></div><div class="">To clarify, are you suggesting that plain variable bindings would support this too (such as "let x = try foo() catch { ... }”)? </div></div></div></blockquote><div><br class=""></div><div>I was responding to this in your original proposal:</div><div><br class=""></div><div> // func foo() throws -><b class=""> T </b>...<br class=""> <b class="">guard let</b> x = try foo catch {</div><div><br class=""></div><div>This is inconsistent with what we currently have, because “if let” and “guard let” match against an optional and succeed iff the optional is present. You were seemingly saying that the presence of “catch” later in the statement would affect this very primitive behavior that we have.</div><div><br class=""></div><div>I’m not a strong believer in this proposal, because it is adding complexity and sugar, but I haven’t seen strong motivation that it is common. This isn’t to say that it isn’t common and worthwhile, just that I haven’t seen any evidence.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I like this idea. I can also foresee the desire for something like this:</div><div class=""><br class=""></div><div class=""> let x = try foo() catch {</div><div class=""> print(error)</div><div class=""> x = bar() // by some syntax, provide a fallback value for x, since foo() threw</div><div class=""> // control flow *can* escape, since x has a value</div><div class=""> }</div></div></div></blockquote><div><br class=""></div><div>We wouldn’t do that though, we’d require guard-like behavior for the same reason we require it for guard: the value of guard is that you *know* that an instance of guard doesn’t fall through, without analyzing its behavior in depth.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Of course, you can achieve this today </div></div></div></blockquote><div><br class=""></div><div>Yes, your proposal is a sugar proposal.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">with "let x; do { x = try foo() } catch { x = bar() }", or with "let x = try? foo() ?? bar()". I just wonder if it's worth considering the possibility that this new feature would allow control flow to escape in some cases. (After all, control flow can exit the "catch" block we have today.) But it's also nice to be able to glance at the code and see that, unambiguously, control flow can't escape the block.</div><div class=""><br class=""></div><div class="">The reason I originally suggested "guard" is readability: Seeing the word "guard", a reader knows that control flow can't escape the else/catch block. But I understand why guard is still necessary for working with optionals/patterns, and I suppose seeing "try" introducing the expression may be enough.</div></div></div></blockquote><div><br class=""></div><div>This shouldn’t be tied to the presence of try, because it already means something (that the enclosed expression can throw). This:</div><div><br class=""></div><div>guard let x = try foo() …</div><div><br class=""></div><div>Already means “call foo, if it throws, propagate the error. If not, test the returned optional”. Changing that based on a subsequent ‘catch’ seems wrong.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Another question: should it work with expressions that don't bind variables? Simply "try foo() catch { ... }" ? (At one point I had considered "<b class="">do</b> try ... catch ...", as a braceless analogue of "<b class="">do</b> { try ... } catch ...”.)</div></div></div></blockquote></div><br class=""><div class="">In my opinion, this whole proposal could be better served with library functions.</div><div class=""><br class=""></div><div class="">-Chris</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>