[swift-evolution] Guard Implicit Fallback

ilya ilya.nikokoshev at gmail.com
Fri Feb 12 01:26:04 CST 2016


Agreed that explicit return is more readable.
I'd be happy to lose brackets around return though:

guard let value = optional else return

On Thu, Feb 11, 2016 at 18:46 Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
> _______________________________________________
> 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/25f4d8fe/attachment.html>


More information about the swift-evolution mailing list