This has been suggested several times before. See the conversations below:<br><br><a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/11563/">http://article.gmane.org/gmane.comp.lang.swift.evolution/11563/</a><br><br><a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/6770/">http://article.gmane.org/gmane.comp.lang.swift.evolution/6770/</a><br><br><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 20, 2016 at 01:30 Yarden Eitan via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></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">Dear community,</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">While using ‘guard’ with much appreciation, I noticed a few cases where I would of hoped for better and more concise code.</div><div><br></div>As of now, you receive a compiler error if your guard statement does not provide an ending statement such as return/break/etc. at the end. <div>It is informative, but in many cases such a statement makes the code repetitive and less concise.</div><div><br></div><div>As an example of cases where there are multiple guards done sequentially to avoid very nested and unclear ‘if's:</div><div><br></div><div>guard let resp = response as? HTTPURLResponse else {</div><div> failure(…)</div><div> return</div><div>}</div><div><br></div><div>guard let resp.statusCode == 200 else {</div><div> failure(…)</div><div> return</div><div>}</div><div><br></div><div>guard let respData = data else {</div><div> failure(…)</div><div> return</div><div>}</div><div><br></div><div>guard let res = parse(respData) else {</div><div> failure(…)</div><div> return</div><div>}</div><div><br></div><div>success(…)</div><div><br></div><div>As you can see in this example, while the different failures can (and should) provide different information for completion, we always have to add a repetitive return after them.</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><div><br></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><br></div><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><div>Glad to hear your thoughts on the matter.</div><div><br></div><div>Best,</div><div>Yarden</div><div><div><div style="font-family:helvetica,arial;font-size:13px"><br></div></div></div></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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>