[swift-evolution] Proposal: Add implicit/default else-behaviour for the guard statement

[Andrey Tarantsov]

I'm conflicted.

Pros:

1) Neat. :-)

2) Um, less typing? But Xcode has snippets, you know.

3) Less visual noise? Perhaps someone considers that visual noise, but to me { return nil } is an essential part of the flow and actually helps to understand it.

4) I would love a “guard!” variant that crashes instead of returning.

Cons:

1) Can no longer find all returns by just looking for 'return'.

2) Reads more like an assertion than like a return.

I believe there are no good arguments one way or another, so we have to fall back on the taste of the core team.

A.


> On Dec 17, 2015, at 2:35 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Wed, Dec 16, 2015, at 04:30 PM, Erica Sadun via swift-evolution wrote:
>> Count me in as a "no". Despite the redundancy, actually spelling out how the else clause leaves scope is valuable to reading the code.
>  
> Agreed. Count me as a "no" as well. `else { return }` is not problematic enough to justify the penalty to reading comprehension.
>  
> -Kevin Ballard
> 
> _______________________________________________
> 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/20151217/819b775e/attachment.html>