<div dir="ltr">Initially, this proposal felt a little off, but on re-reading, I think I like it very much. It shows that guard/catch is meant to solve a nesting problem (just like guard/else was meant to solve one), and it preserves the idea that the else/catch clause must exit the outer scope, which is very important to the meaning of `guard`.<div><br></div><div>I agree with the proposal authors that mix-and-match guard/catch/else feels unwise. I see no reason why rewriting to repeat only the word `guard` (as in, `guard A catch { }; guard B else { }` instead of `guard A, B catch { } else { }`) is onerous enough to justify a syntax that is clearly harder to reason about.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 5, 2017 at 2:25 PM, Soroush Khanlou 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Jon — we explored allowing users to mix and match optional unwrapping and error catching in the same guard, but found that it was ultimately pretty confusing. We think that guard/else and guard/catch should be two totally different components. Dave’s email lays out the two best approaches, and the “Alternatives Considered” section of the proposal goes into why those alternatives were ultimately rejected.<div><div class="h5"><div><br><div><blockquote type="cite"><div>On Jul 5, 2017, at 2:09 PM, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_1325906598329062923Apple-interchange-newline"><div><div style="word-wrap:break-word">Soroush’s proposal has the idea that maybe we could do multiple blocks for this scenario, like so:<div><br></div><div><font face="Menlo"><span style="font-size:11px">guard try something(), let thing = optionalThing catch {</span></font></div><div><font face="Menlo"><span style="font-size:11px"> // try something() failed</span></font></div><div><font face="Menlo"><span style="font-size:11px">} else {</span></font></div><div><font face="Menlo"><span style="font-size:11px"> // the let-binding failed</span></font></div><div><font face="Menlo"><span style="font-size:11px">}</span></font></div><div><br></div><div>🤔 Alternatively, what if the “error” captured was optional in this scenario?</div><div><br></div><div><font face="Menlo"><span style="font-size:11px">guard try something(), let thing = optionalThing catch {</span></font></div><div><font face="Menlo"><span style="font-size:11px"> if let error = error {</span></font></div><div><font face="Menlo"><span style="font-size:11px"> // the try call failed</span></font></div><div><font face="Menlo"><span style="font-size:11px"> } else {</span></font></div><div><font face="Menlo"><span style="font-size:11px"> // the optional binding failed</span></font></div><div><font face="Menlo"><span style="font-size:11px"> }</span></font></div><div><font face="Menlo"><span style="font-size:11px">}</span></font></div><div><br></div><div>Dave</div><div><br><div><blockquote type="cite"><div>On Jul 5, 2017, at 12:00 PM, Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_1325906598329062923Apple-interchange-newline"><div><div style="word-wrap:break-word"><span class="m_1325906598329062923Apple-tab-span" style="white-space:pre-wrap"> </span>I didn’t think I was going to like it but I really do. My only concern, which isn’t really a deal breaker, is what it would look like to chain multiple try and let statement in the same guard. Unless that scenario works well I don’t think you could convince others. i.e. In the case where I have:<div><br></div><div>guard try something(), let thing = optionalThing catch { }</div><div><br></div><div>What happens when the let fails? No implicit error?</div><div><br></div><div><br></div><div><br></div><div>Jon</div><div><br></div><div><br><div><div><blockquote type="cite"><div>On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_1325906598329062923Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>I’d like to propose a guard/catch construct to the language. It would allow code to use throwing functions and handle errors fully, without straying from a happy path. do/catch can be a bit heavy-handed sometimes, and it would be nice to be able to handle throwing functions without committing to all the nesting and ceremony of do/catch.</div><div><br></div><div>Full proposal, which discusses all the corner cases and alternatives:</div><div><a href="https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9" target="_blank">https://gist.github.com/<wbr>khanlou/<wbr>8bd9c6f46e2b3d94f0e9f037c775f5<wbr>b9</a></div><div><br></div><div>Looking forward to feedback!</div><div><br></div><div>Soroush</div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></div></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>