<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><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"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><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></body></html>