<div dir="ltr">I like the general elegance of aligning this with existing constructs, but ultimately it would be of little use to me. Usually if a guard fails, I want to log a message, or increment a counter, or at the very least have a statement that I can stick a breakpoint on. This proposal is appealing to me from a brevity POV, but I suspect that if it were adopted, a lot of organizations would adopt code conventions that ban it so that you can more easily follow the control flow when debugging.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 11:19 PM, Alexey Demedetskiy via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey all<br>
<br>
Can we align `guard` statement with `as` and `try` statements?<br>
<br>
I mean enabling `guard?` and `guard!` versions.<br>
<br>
guard! behavior is a pretty straightforward - raise an exception if condition is false.<br>
In this case it will look like precondition(), but with conditional bindings.<br>
<br>
guard? is a tricky one. What actually want to say - return default value.<br>
in Void returning functions it is simple. It can be obvious in an Optional returning functions.<br>
But this use cases are not general enough.<br>
<br>
In other words, to give guard? statements enough semantics, we need to provide default return value<br>
to function signature.<br>
<br>
So, given small setup:<br>
<br>
typealias UserID = Int<br>
struct User { let id: UserID }<br>
<br>
let users = [User(id: 1), User(id: 2)]<br>
<br>
We can write findUser(byID:) function this way:<br>
<br>
func findUser(byId id: UserID?) -> User? {<br>
guard let id = id else { return nil }<br>
<br>
for user in users {<br>
if <a href="http://user.id" rel="noreferrer" target="_blank">user.id</a> == id { return user }<br>
}<br>
<br>
return nil<br>
}<br>
<br>
And with guard? and function default return values this way:<br>
<br>
func findUser(byId id: UserID?) -> User? = nil {<br>
guard? let id = id<br>
<br>
for user in users {<br>
if <a href="http://user.id" rel="noreferrer" target="_blank">user.id</a> == id { return user }<br>
}<br>
}<br>
<br>
Function default return values is an off topic here and can be moved to separate thread if anyone is interested.<br>
<br>
Best regards,<br>
Alexey Demedetskiy<br>
<span class=""><br>
> Hey everyone,<br>
><br>
> I feel that `guard` could be a little more Swifty and would like to start a conversation concerning it.<br>
><br>
> 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.<br>
><br>
> Can we improve on the general fallback case? Could we simply say:<br>
><br>
> func noReturn() {<br>
> guard let aValue = someOptional<br>
> ....<br>
> }<br>
><br>
</span>> and have that imply "else { returnvoid or nil}"<br>
<span class="im HOEnZb">><br>
> What are your thoughts?<br>
><br>
> Tighe<br>
><br>
><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div></div>