[swift-evolution] Guard Implicit Fallback

[Xiaodi Wu]

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.

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.
On Thu, Feb 11, 2016 at 11:38 AM Developer via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.
>
> ~Robert Widmann
>
> 2016/02/10 22:40、Tighe Racicot via swift-evolution <
> swift-evolution at swift.org> のメッセージ:
>
> 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 { return *void or nil* }"
>
> What are your thoughts?
>
> Tighe
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/20160211/3037eb7a/attachment.html>