<div dir="ltr">On Mon, Jun 20, 2016 at 10:04 PM, Yarden Eitan via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div 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></blockquote><div><br></div><div>Swift, by design, does not permit if statements without braces. It also, by design, does not have optional warnings.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div 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?</div></div></blockquote><div><br></div><div>A `guard` statement is a control flow statement. It indicates that you are prematurely exiting the scope, and therefore by design it requires you to explain how you intend to do so.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">‘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 style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div 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 style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div 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><span class="HOEnZb"><font color="#888888"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Yarden</div></font></span><div><div class="h5"> <br> <div><div style="font-family:helvetica,arial;font-size:13px"><br></div></div> <br><p>On June 20, 2016 at 5:29:17 PM, Dany St-Amant (<a href="mailto:dsa.mls@icloud.com" target="_blank">dsa.mls@icloud.com</a>) wrote:</p> <blockquote type="cite"><span><div dir="auto"><div></div><div>
<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" target="_blank">swift-evolution@swift.org</a>>
a écrit :<br>
<br></div>
<blockquote type="cite">
<div 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></div></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></div>