<div style="white-space:pre-wrap">Losing brackets around the return would mean that no additional statements (for example logging or some other useful thing) will be possible in the early return</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 12, 2016 at 2:26 AM ilya 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="white-space:pre-wrap">Agreed that explicit return is more readable. <br>I'd be happy to lose brackets around return though:<br><br>guard let value = optional else return</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 11, 2016 at 18:46 Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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">I believe this has already been proposed on the list in the past. I don't have easy access to the archives at the moment so I can't provide a convenient link.<br><br>The gist of it--or at least one of the compelling arguments against the idea--was that the 'obvious' implicit behavior becomes non-obvious when you take into account guard statements inside loops, for example. Do you continue? break? return? And once you make a decision for each of the scenarios envisioned you end up with a complicated series of fallbacks that need extensive documentation, which is no longer much of a win over explicitly writing your fallback.<br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 11, 2016 at 11:38 AM Developer via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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 dir="auto"><div>I agree the nil fallback case is a common one, but the loss of readability and decreased understanding of control flow here makes me think special-casing this isn't all it's cracked up to be.</div><div><br></div><div>~Robert Widmann</div><div><br>2016/02/10 22:40、Tighe Racicot via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> のメッセージ:<br><br></div></div><div dir="auto"><blockquote type="cite"><div><div dir="ltr">Hey everyone, <div><br></div><div>I feel that `guard` could be a little more Swifty and would like to start a conversation concerning it.</div><div><br></div><div>For example, I often have a function whose job depends on an optional having a value, and so I guard-let at the start and return if the guard fails. Or if the function returns an optional type, I'll simply return nil if guard fails. </div><div><br></div><div>Can we improve on the general fallback case? Could we simply say:</div><div><br></div>func noReturn() {<br> guard let aValue = someOptional<br><div> ....</div><div>}</div><div><br></div><div>and have that imply "else { return <i>void or nil</i> }"</div><div><br></div><div>What are your thoughts?</div><div><br></div><div>Tighe</div><div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></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>
_______________________________________________<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>
_______________________________________________<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>