<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I’m also against, for two reasons:</div><div class=""><br class=""></div><div class="">- looking at my code, `return` and `return nil` are most common, but not super-overwhelmingly so. I’m all for common-sense default behavior, but here, I’m just not convinced it’s worth it. Likewise, I hate noise in code, but I’m not bothered by explicit `else` blocks at all.</div><div class="">- guard is already confusing enough until you truly, fully get it. Having an `else` block makes it far more clearer that it’s a (specialized) branching operation. Having something implicitly return from my method sounds almost scary.</div><br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 17 Dec 2015, at 00:26, Stephen Celis via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I'm opposed. I don't think `else { return }` is enough of a mouthful to add a default behavior that must be learned and reasoned with.<div class=""><br class=""></div><div class="">Stephen</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Dec 16, 2015 at 5:36 PM, Vester Gottfried via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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 class=""><br class=""></div><div class="">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" class=""> In my case </span><span style="font-size:13px" class="">80% of all guard statements end with </span><span style="font-size:13px" class="">"else { return }"</span><span style="font-size:13px" class=""> or </span><span style="font-size:13px" class="">"else { return nil }". </span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Dec 16, 2015 at 11:20 PM, Etan Kissling via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">If guard defaults to something context-dependent, it's also counterintuitive.<div class=""><br class=""></div><div class=""><br class=""></div><div class="">Me personally is fine with guard x > 0 returning from the function in this case.</div><div class=""><br class=""></div><div class="">I use guard mainly as a glorified assert that allows safe exit from the function instead of crashing the program on fail.</div><div class="">If you think about it that way, it's perfectly reasonable that it returns in all cases.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class="">Maybe OP could post additional statistics of the number cases where "guard ... else { return }" is used inside a breakable scope.</div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Etan</div><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 16 Dec 2015, at 23:15, Vinicius Vendramini <<a href="mailto:vinivendra@gmail.com" target="_blank" class="">vinivendra@gmail.com</a>> wrote:</div><br class=""><div class="">
<div style="word-wrap:break-word" class=""><div class="">Bringing up a possible edge case:</div><div class=""><br class=""></div><div class="">func foo() {</div><div class=""> while(…) {</div><div class=""> guard x > 0</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">if guard defaulted to return even inside a while (as was suggested), this might be counterintuitive.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 16, 2015, at 5:06 PM, Etan Kissling via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class="">
<div style="word-wrap:break-word" class="">
Also +1 on default return, -1 on default continue / break, and -1 for removing braces
<div class=""><br class="">
</div>
<div class="">Instead of VoidLiteralConvertible, one could extend on the idea with something that is not specifically tailored to nil, like</div>
<div class=""><br class="">
</div>
<div class="">func foo(x: Int) -> Int = 5 {</div>
<div class=""> guard x < 10 // Would return default 5 for x >= 10</div>
<div class=""><br class="">
</div>
<div class=""> if x > 5 {</div>
<div class=""> return // Would return default 5</div>
<div class=""> }</div>
<div class=""> return x</div>
<div class="">}</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Etan</div>
<div class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 16 Dec 2015, at 19:39, Ian Ynda-Hummel via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div>
<br class="">
<div class="">
<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" class="">
<div class="">I am also +1 for implicit return, but -1 on continue/break for the reasons already stated.</div>
<div class=""><br class="">
</div>
I'm -1 for removing braces for one-liners. I think maintaining braces around blocks helps distinguish them from expressions. For example,
<div class=""><span style="line-height:1.5" class=""><br class="">
</span></div>
<div class=""><span style="line-height:1.5" class=""> guard</span><span style="line-height:1.5" class=""><span class=""> </span>x < 1</span><span style="line-height:1.5" class="">0</span><span style="line-height:1.5" class=""><span class=""> </span></span><span style="line-height:1.5" class="">else</span><span style="line-height:1.5" class=""><span class=""> </span></span><span style="line-height:1.5" class="">return</span><br class="">
</div>
<div class=""><span style="line-height:1.5" class=""><br class="">
</span></div>
<div class=""><span style="line-height:1.5" class="">would catch me off guard (pardon the pun).</span></div>
<div class=""><span style="line-height:1.5" class=""><br class="">
</span></div>
<div class="">I think I'm -1 on VoidLiteralConvertible, but I'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't intend to as the compiler wouldn't complain about a missing return value. I don'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" class="">
<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" class="">On Wed, Dec 16, 2015 at 11:59 AM ilya via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
</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" class="">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's best to always return them explicitly. <br class="">
<br class="">
Oh, and it would help with default values, e.g.<br class="">
<br class="">
var something:Something?<br class="">
// where does the default value come from? VoidLiteralConvertible! <br class="">
<br class="">
I want all default values for String in this scope be "none":<br class="">
<br class="">
private extension String: VoidLiteralConvertible { ... return "None" ... }</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Wed, Dec 16, 2015 at 10:49 ilya <<a href="mailto:ilya.nikokoshev@gmail.com" target="_blank" class="">ilya.nikokoshev@gmail.com</a>> wrote:<br class="">
</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" class="">+1 on default return <br class="">
<br class="">
-1 on default continue or break, this is ambiguous. <br class="">
Even inside switch it's not clear if guard should break or return, so let's not make people guess. .
<br class="">
<br class="">
Also can we stop requiring braces for simple one-liners: <br class="">
<br class="">
guard x<10 else return 5<br class="">
<br class="">
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 class="">
</div>
<div style="white-space:pre-wrap" class=""><br class="">
> swift would provide a warning that the guard statement needs an else block<br class="">
<br class="">
</div>
<div style="white-space:pre-wrap" class="">In this specific case the compiler basically has to guess, so an error seems more appropriate.
<br class="">
</div>
<div style="white-space:pre-wrap" class=""><br class="">
Ilya. </div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Wed, Dec 16, 2015 at 02:53 Vester Gottfried via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
</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" class=""><font face="monospace, monospace" class="">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 class="">
<br class="">
In a current project I found 217 guard statements from which 183 have repetitive else clauses<br class="">
<br class="">
From which:<br class="">
131 end with "else { return nil }"<br class="">
44 "else { return }"<br class="">
6 "else { continue }"<br class="">
2 "else { break }"<br class="">
<br 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">
<span class=""> </span> </div>
guard x < 10<br class="">
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
<span class=""> </span> </div>
...<br class="">
}<br class="">
<br class="">
swift would implicitly add "else { return }"<br class="">
<br class="">
--<br class="">
<br class="">
func foo(x: Int) -> Int? {<br class="">
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
<span class=""> </span> </div>
guard x < 10<br class="">
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
<span class=""> </span> </div>
...<br class="">
}<br class="">
<br class="">
swift would implicitly add "else { return nil }"<br class="">
<br class="">
--<br class="">
<br class="">
for i in 0..<10 {<br class="">
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
<span class=""> </span> </div>
guard i%2 == 0<br class="">
}<br class="">
<br class="">
swift would implicitly add "else { continue }"<br class="">
<br class="">
--<br class="">
<br class="">
switch {<br class="">
case a :<br class="">
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
<span class=""> </span> </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">
<span class=""> </span> ...</div>
<br class="">
}<br class="">
<br class="">
swift would implicitly add "else { break }"<br class="">
<br class="">
--<br class="">
<br class="">
func foo(x: Int) -> Int {<br class="">
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
<span class=""> </span> </div>
guard x < 10<br class="">
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
<span class=""> </span> </div>
...<br class="">
}<br class="">
<br class="">
swift would provide a warning that the guard statement needs an else block<br class="">
<br class="">
--<br class="">
<br class="">
Possible advantages<br class="">
- Less code
<div class="gmail_default" style="font-family:monospace,monospace;display:inline">
<span class=""> </span>to write</div>
<br class="">
- visually cleaner<br class="">
-
<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 class="">
<br class="">
<br class="">
Possible Disadvantages<br class="">
- Different behaviour in different contexts (func/return, for/continue, switch/break, …) needs to be learned and understood<br class="">
- programmers might forget that guard + else {} is an option</font><br class="">
</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" class=""><span class=""> </span>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</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" class=""><span class=""> </span>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</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" class=""><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" class=""><span class=""> </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" class="">
<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" class="">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" class="">
<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" class="">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" class="">
<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div>
</blockquote>
</div>
<br class="">
</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" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></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" class="">
</div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=4hhvaxvZNsLrnZM9llg93kxoqfFYC8lhv8HAehOIDqJB8rxnJsob02K4mVNRcmTEAH-2BJ9VYS3oEvZYSJuIeqEN3Q-2FLwnQXZhZYkoFRGXKzzskB7M1Q3qVK-2FpPm8V0sHkL0n-2BrvPRjAlKP9AYO-2BCb0cOp2BiHRm0vWFJAJRqZ1rSTgVt2-2BqEDHagbINkK4c2Cc-2FrJy9vck2s9Cuj17obgG10pPDMpbwU8irOwbPW7BZg-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;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>