<div dir="ltr"><div>I am also +1 for implicit return, but -1 on continue/break for the reasons already stated.</div><div><br></div>I&#39;m -1 for removing braces for one-liners. I think maintaining braces around blocks helps distinguish them from expressions. For example,<div><span class="s1" style="line-height:1.5"><br></span></div><div><span class="s1" style="line-height:1.5">    guard</span><span class="s2" style="line-height:1.5"> x &lt; 1</span><span class="s3" style="line-height:1.5">0</span><span class="s2" style="line-height:1.5"> </span><span class="s1" style="line-height:1.5">else</span><span class="s2" style="line-height:1.5"> </span><span class="s1" style="line-height:1.5">return</span><br></div><div><span class="s1" style="line-height:1.5"><br></span></div><div><span class="s1" style="line-height:1.5">would catch me off guard (pardon the pun).</span></div><div><span class="s1" style="line-height:1.5"><br></span></div><div>I think I&#39;m -1 on VoidLiteralConvertible, but I&#39;m somewhat undecided. I think that separating the return value from the actual return point could lead to a lot of confusion, and would subsequently also make it easy to accidentally return the default value when you didn&#39;t intend to as the compiler wouldn&#39;t complain about a missing return value.  I don&#39;t think I have totally convinced myself that the latter is a non-trivial problem, but I thought it was worth mentioning.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 16, 2015 at 11:59 AM ilya via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">Actually I thought about VoidLiteralConvertible some more and now I think if we include it the only nontrivial case in the standard library case should be Optional.Nonel. Empty arrays and dictionaries are different from nothing, so it&#39;s best to always return them explicitly. <br><br>Oh, and it would help with default values, e.g.<br><br>var something:Something?<br>// where does the default value come from? VoidLiteralConvertible! <br><br>I want all default values for String in this scope be &quot;none&quot;:<br><br>private extension String: VoidLiteralConvertible { ... return &quot;None&quot; ... }</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 16, 2015 at 10:49 ilya &lt;<a href="mailto:ilya.nikokoshev@gmail.com" target="_blank">ilya.nikokoshev@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">+1 on default return <br><br>-1 on default continue or break, this is ambiguous. <br>Even inside switch it&#39;s not clear if guard should break or return, so let&#39;s not make people guess. . <br><br>Also can we stop requiring braces for simple one-liners: <br><br>guard x&lt;10 else return 5<br><br>As for default return values, we could create a VoidLiteralConvertible, so that default return automatically becomes return nil or return [] in an Optional or Array context respectively. As a bonus, it will be technically possible to override this behavior inside a specific function scope. <br></div><div style="white-space:pre-wrap"><br>&gt; swift would provide a warning that the guard statement needs an else block<br><br></div><div style="white-space:pre-wrap">In this specific case the compiler basically has to guess, so an error seems more appropriate. <br></div><div style="white-space:pre-wrap"><br>Ilya. </div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 16, 2015 at 02:53 Vester Gottfried via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><font face="monospace, monospace">I find myself writing the same else blocks for guard statements over and over again, so it might be reasonable to think about a default behaviour.<br><br>In a current project I found 217 guard statements from which 183 have repetitive else clauses<br><br>From which:<br>131 end with &quot;else { return nil }&quot;<br>44 &quot;else { return }&quot;<br>6 &quot;else { continue }&quot;<br>2 &quot;else { break }&quot;<br><br>My proposal would be to make the else block optional and define a default behaviour.<br><br>For example:<br><br>func foo(x: Int) {<br><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ​</div>guard x &lt; 10<br><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ​</div>...<br>}<br><br>swift would implicitly add &quot;else { return }&quot;<br><br>--<br><br>func foo(x: Int) -&gt; Int? {<br><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ​</div>guard x &lt; 10<br><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ​</div>...<br>}<br><br>swift would implicitly add &quot;else { return nil }&quot;<br><br>--<br><br>for i in 0..&lt;10 {<br><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ​</div>guard i%2 == 0<br>}<br><br>swift would implicitly add &quot;else { continue }&quot;<br><br>--<br><br>switch {<br>case a :<br><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ​</div>guard x != y<br>case b :</font><div><font face="monospace, monospace"><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ...​</div><br>}<br><br>swift would implicitly add &quot;else { break }&quot;<br><br>--<br><br>func foo(x: Int) -&gt; Int {<br><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ​</div>guard x &lt; 10<br><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​    ​</div>...<br>}<br><br>swift would provide a warning that the guard statement needs an else block<br><br>--<br><br>Possible advantages<br>- Less code<div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ to write​</div><br>- visually cleaner<br>-<div class="gmail_default" style="font-family:monospace,monospace;display:inline">​ ​</div>In code with multiple guard statements<div class="gmail_default" style="display:inline">​ ​</div>you<div class="gmail_default" style="display:inline">​ ​</div>would not have to repeat the else block<br><br><br>Possible Disadvantages<br>- Different behaviour in different contexts (func/return, for/continue, switch/break, …) needs to be learned and understood<br>- programmers might forget that guard + else {} is an option</font><br></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1p9Jer2O6jVE9KWvo-2B9iUaEyN8slp4IizyiLwsfp54Nq6HB1QvDr1NATTiNVHM5FeRnZlEYkvBM4a9SOK9uUTg-2BKC5LbuPWspn7WIdvJStDdL7cEklJGmF7ns38m-2FKlGgd9MjsXwAa1k0rLKghHgarLpkoGqHTF9JIDwQ2YLp79pV5tTFvxeEMB0tN6N7G9ck9PoGgGpWWLOInd26COTyoubf2xkRWCqHceU0vu4cVQ-3D" alt="" width="1" height="1" border="0" style="min-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">
_______________________________________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></blockquote></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=t5fkNsX-2F7-2FAygTFNPNE08PALgkjkO6I8wpsdssDS0ujZY5P9vBLfqz65hb0zEcOZ2tVKrT5CpPLK-2BDFckSfHeJRQIAc4R5G5miuYly6lTh7kICRixRvR73QdPQe4GS3yI9dMOVt4bJ1hZ-2FCJQYsofdD4Ve6YA75oUM9SYzZJP-2Bycbbm-2BuEDzxQ7K9Cmc7Ym7oFezb-2BWxnpAND1s-2BSX-2Bh-2FJXCk1KlXO8nxizWqzum-2FSg-3D" alt="" width="1" height="1" border="0" style="min-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">
_______________________________________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>