<div dir="ltr">I&#39;m opposed. I don&#39;t think `else { return }` is enough of a mouthful to add a default behavior that must be learned and reasoned with.<div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 5:36 PM, Vester Gottfried via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I just skipped through 200+ guard statements that return Void, nil or a value and no statement was inside a scope that can be exited with break. <div><br></div><div>I am also thinking about the proposals regarding default values to return, but I am not sure if this would even be necessary. <span style="font-size:13px"> In my case </span><span style="font-size:13px">80% of all guard statements end with </span><span style="font-size:13px">&quot;else { return }&quot;</span><span style="font-size:13px"> or </span><span style="font-size:13px">&quot;else { return nil }&quot;. </span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 11:20 PM, Etan Kissling via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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">If guard defaults to something context-dependent, it&#39;s also counterintuitive.<div><br></div><div><br></div><div>Me personally is fine with guard x &gt; 0 returning from the function in this case.</div><div><br></div><div>I use guard mainly as a glorified assert that allows safe exit from the function instead of crashing the program on fail.</div><div>If you think about it that way, it&#39;s perfectly reasonable that it returns in all cases.</div><div><br></div><div><br></div><div><br></div><div>On the other hand, the implicit default else behaviour could only trigger if there is no outer scope that can be exited with break.</div><div>Maybe OP could post additional statistics of the number cases where &quot;guard ... else { return }&quot; is used inside a breakable scope.</div><div><div><br></div><div><br></div><div>Etan</div><div><div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On 16 Dec 2015, at 23:15, Vinicius Vendramini &lt;<a href="mailto:vinivendra@gmail.com" target="_blank">vinivendra@gmail.com</a>&gt; wrote:</div><br><div>
<div style="word-wrap:break-word"><div>Bringing up a possible edge case:</div><div><br></div><div>func foo() {</div><div>    while(…) {</div><div>        guard x &gt; 0</div><div>    }</div><div>}</div><div><br></div><div>if guard defaulted to return even inside a while (as was suggested), this might be counterintuitive.</div><br><div><blockquote type="cite"><div>On Dec 16, 2015, at 5:06 PM, Etan Kissling via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div>



<div style="word-wrap:break-word">
Also +1 on default return, -1 on default continue / break, and -1 for removing braces
<div><br>
</div>
<div>Instead of VoidLiteralConvertible, one could extend on the idea with something that is not specifically tailored to nil, like</div>
<div><br>
</div>
<div>func foo(x: Int) -&gt; Int = 5 {</div>
<div>    guard x &lt; 10 // Would return default 5 for x &gt;= 10</div>
<div><br>
</div>
<div>    if x &gt; 5 {</div>
<div>        return // Would return default 5</div>
<div>    }</div>
<div>    return x</div>
<div>}</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Etan</div>
<div>
<div><br>
</div>
<div><br>
<div>
<blockquote type="cite">
<div>On 16 Dec 2015, at 19:39, Ian Ynda-Hummel via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div>
<br>
<div>
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<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 style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">    guard</span><span style="line-height:1.5"><span> </span>x &lt; 1</span><span style="line-height:1.5">0</span><span style="line-height:1.5"><span> </span></span><span style="line-height:1.5">else</span><span style="line-height:1.5"><span> </span></span><span style="line-height:1.5">return</span><br>
</div>
<div><span style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">would catch me off guard (pardon the pun).</span></div>
<div><span 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 style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir="ltr">On Wed, Dec 16, 2015 at 11:59 AM ilya 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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">
​<span> </span>   ​</div>
guard x &lt; 10<br>
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
​<span> </span>   ​</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">
​<span> </span>   ​</div>
guard x &lt; 10<br>
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
​<span> </span>   ​</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">
​<span> </span>   ​</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">
​<span> </span>   ​</div>
guard x != y<br>
case b :</font>
<div><font face="monospace, monospace">
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
​<span> </span>   ...​</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">
​<span> </span>   ​</div>
guard x &lt; 10<br>
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
​<span> </span>   ​</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">
​<span> </span>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 alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"><span> </span>_______________________________________________<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 alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"><span> </span>_______________________________________________<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>
<img alt="" width="1" height="1" border="0" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"><span> </span>_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">swift-evolution
 mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div>
</blockquote>
</div>
<br>
</div>
</div>

<img 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">
</div>


_______________________________________________<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/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div></div></div></div></div><br>_______________________________________________<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>
<br></blockquote></div><br></div>
<img 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">
</div></div><br>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>