<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Looking at the numbers it would make sense mostly to return from a function. And I agree with David that control flow in loops and switches should be explicit.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">So maybe a function could declare a default behavior for all its `guard`</div><div id="AppleMailSignature"><br>Pierre</div><div><br>Le 16 déc. 2015 à 01:42, David Waite via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; a écrit&nbsp;:<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 Dec 15, 2015, at 4:53 PM, Vester Gottfried via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><div class=""><div dir="ltr" class=""><font face="monospace, monospace" class=""><br class=""></font></div></div></blockquote>&lt;snip&gt;</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><font face="monospace, monospace" class="">My proposal would be to make the else block optional and define a default behaviour.<br class=""><br class="">For example:<br class=""><br class="">func foo(x: Int) {<br class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;​</div>guard x &lt; 10<br class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;​</div>...<br class="">}<br class=""><br class="">swift would implicitly add "else { return }”<br class=""><br class=""></font></div></div></blockquote><div><br class=""></div>That makes sense</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><font face="monospace, monospace" class="">--<br class=""><br class="">func foo(x: Int) -&gt; Int? {<br class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;​</div>guard x &lt; 10<br class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;​</div>…<br class="">}<br class=""><br class=""></font></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><font face="monospace, monospace" class="">swift would implicitly add "else { return nil }”<br class=""><br class=""></font></div></div></blockquote>You would need to decide how this plays into the type system&nbsp;</div><div>- is Optional a special case</div><div>- or, will it work with anything NilLiteralConvertible (Optional, ImplicitlyUnwrappedOptional, Pointer types, Selectors)</div><div><br class=""></div><div>I thought of using the no-argument initializer, but that creates too much default behavior (empty arrays, zero doubles, etc).&nbsp;</div><div><br class=""></div><div>Plus, it is inconsistent with variable declarations, which require explicit initialization before use.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><font face="monospace, monospace" class="">--<br class=""><br class="">for i in 0..&lt;10 {<br class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;​</div>guard i%2 == 0<br class="">}</font></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><font face="monospace, monospace" class="">swift would implicitly add "else { continue }”</font></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><font face="monospace, monospace" class="">switch {</font></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><font face="monospace, monospace" class="">case a :<br class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;​</div>guard x != y<br class="">case b :</font><div class=""><font face="monospace, monospace" class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;...​</div><br class="">}</font></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><span style="font-family: monospace, monospace;" class="">swift would implicitly add "else { break }"</span></div></div></div></blockquote><div><br class=""></div><div>-1 . Flow control functions need to be explicit, else I risk having (and assuming) the wrong behavior when I copy and paste code from one context to another.</div><div><br class=""></div><div>Plus, why would I expect a guard in a for loop to break or continue as a default behavior? I personally know I would constantly think this guard as ‘does what I mean’, while in the debugger it seems to be doing exactly the opposite of what I assumed, every time, regardless of my assumption ;-)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><font face="monospace, monospace" class=""><br class="">func foo(x: Int) -&gt; Int {<br class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;​</div>guard x &lt; 10<br class=""><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ &nbsp; &nbsp;​</div>...<br class="">}<br class=""><br class="">swift would provide a warning that the guard statement needs an else block<br class=""></font></div></div></div></blockquote><div><br class=""></div>Iff your proposal was to call the no-argument initializer, this would return 0. For the other options this would need to return an error, not a warning.&nbsp;</div><div><br class=""></div><div>-DW</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ST9LHNQ2kYRKURQJ7G-2FmGCudH8brFLVBGfh-2Becw1t9jCsGON2iwXmiHOlOSj7mI0DyrZxJ9JLIzEP1XF2TbQ8iKUjydT-2BJFxeHvlyhjB1fK7OnL8F5f-2BEAAhXWQs1HrOLZ7gZSn02H7JH5nhNZ9a1LRQO1yHeLkCp9kzbvHdZqbZX3PNvdhEX2b9Zt0Etdq0nkd9irEgROtZKPcMZzTuZ0xvdpieo5kN8Ui2QwjmLvM-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">

</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>