<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I agree that by having different implicit ending statements (i.e. break/return/etc.) based on context makes it more complicated and less intuitive. Having said that, I do think that an implicit ‘return’ with/without a warning (rather than an error), gives people the opportunity to either exclude or include the ‘return’ statement if they wish. This give the developers the optionality to choose what is the better code design based on their personal preference (like one liner ‘if’s with or without brackets). I do think that if there is a warning, it should also have the option to be suppressed. </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">If you think the ‘return’ statement has to be stated, then why don’t we enforce a ‘return’ statement at the end of void functions? ‘guard’ should be treated and recognized in a way that ‘return’ is obvious, like void function endings. I agree that because it is a new thing, it might take time for people to see it as obviously as that.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Looking at the previous requests for this, it seems like it is a pain point for several developers who see it redundant as most of their “guard”s use the same “return” or “return nil” statement. </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I think this current solution gives both ends the needed flexibility.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Yarden</div> <br> <div id="bloop_sign_1466477460116390912" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px"><br></div></div> <br><p class="airmail_on">On June 20, 2016 at 5:29:17 PM, Dany St-Amant (<a href="mailto:dsa.mls@icloud.com">dsa.mls@icloud.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div dir="auto"><div></div><div>
<title></title>
<div><br></div>
<div>
<div><br></div>
Le 20 juin 2016 à 02:30, Yarden Eitan via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
a écrit :<br>
<br></div>
<blockquote type="cite">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
...</div>
<div><br></div>
<div>My proposal is to allow for an implicit return when no ending
statement is provided. We could take this one step further and have
the compiler aware of it’s most inner scope and see if it is a
while loop for example and implicitly allow a break. But I think at
least as a first step, by having an implicit “return” we are saving
the repetitiveness on many cases where there are multiple guard
statements and the return from them is obvious.</div>
</blockquote>
<div><br></div>
<span style="background-color:rgba(255,255,255,0)">A 'guard'
in a loop can commonly be used with either 'continue' or 'break',
the compiler would not be able to guess your intent. And whatever
default would be selected, it would be the wrong one for many
scenarios.</span>
<div><span style="background-color:rgba(255,255,255,0)"><br></span></div>
<div><span style="background-color:rgba(255,255,255,0)">The
'return' is an important keyword which, I think, should not be
obfuscated as one often need to quickly find all exit point of a
function, when debugging/analyzing code.</span></div>
<div><br></div>
<blockquote type="cite">
<div>
<div>This goes along the line of the Swift “switch” statement,
which doesn’t follow it’s predecessors and force a “break” but
rather it is already implicitly there.</div>
</div>
</blockquote>
<div><br></div>
If you bring the consistency card, I would be more on the page of
making 'break' mandatory and explicit in the 'switch'.
<div><br></div>
<div>Dany<br>
<div><br>
<blockquote type="cite">
<div>If this proposal is too much of a leap, an alternative is to
allow an implicit return but provide a warning (not an error). This
warning can be suppressed using an @implicitreturn prefix to the
guard statement or something along those lines (@implicitreturn
guard a = b else { print(“foo”) } ).</div>
<div><br></div>
</blockquote>
</div>
</div>
</div></div></span></blockquote></body></html>