[swift-evolution] Guard Implicit Fallback

[Jonathan Tang]

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.

On Thu, Feb 11, 2016 at 11:19 PM, Alexey Demedetskiy via swift-evolution <
swift-evolution at swift.org> wrote:

> Hey all
>
> Can we align `guard` statement with `as` and `try` statements?
>
> I mean enabling `guard?` and `guard!` versions.
>
> guard! behavior is a pretty straightforward - raise an exception if
> condition is false.
> In this case it will look like precondition(), but with conditional
> bindings.
>
> guard? is a tricky one. What actually want to say - return default value.
> in Void returning functions it is simple. It can be obvious in an Optional
> returning functions.
> But this use cases are not general enough.
>
> In other words, to give guard? statements enough semantics, we need to
> provide default return value
> to function signature.
>
> So, given small setup:
>
> typealias UserID = Int
> struct User { let id: UserID }
>
> let users = [User(id: 1), User(id: 2)]
>
> We can write findUser(byID:) function this way:
>
> func findUser(byId id: UserID?) -> User? {
>     guard let id = id else { return nil }
>
>     for user in users {
>         if user.id == id { return user }
>     }
>
>     return nil
> }
>
> And with guard? and function default return values this way:
>
> func findUser(byId id: UserID?) -> User? = nil {
>     guard? let id = id
>
>     for user in users {
>         if user.id == id { return user }
>     }
> }
>
> Function default return values is an off topic here and can be moved to
> separate thread if anyone is interested.
>
> Best regards,
> Alexey Demedetskiy
>
> > Hey everyone,
> >
> > I feel that `guard` could be a little more Swifty and would like to
> start a conversation concerning it.
> >
> > 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.
> >
> > Can we improve on the general fallback case? Could we simply say:
> >
> > func noReturn() {
> > guard let aValue = someOptional
> > ....
> > }
> >
> > and have that imply "else { returnvoid or nil}"
> >
> > What are your thoughts?
> >
> > Tighe
> >
> >
> >
> >
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160212/e5bd9ba0/attachment.html>