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

ilya ilya.nikokoshev at gmail.com
Wed Dec 16 01:49:37 CST 2015


+1 on default return

-1 on default continue or break, this is ambiguous.
Even inside switch it's not clear if guard should break or return, so let's
not make people guess. .

Also can we stop requiring braces for simple one-liners:

guard x<10 else return 5

As for default return values, we could create a VoidLiteralConvertible, so
that default return automatically becomes return nil or return [] in an
Optional or Array context respectively. As a bonus, it will be technically
possible to override this behavior inside a specific function scope.

> swift would provide a warning that the guard statement needs an else block

In this specific case the compiler basically has to guess, so an error
seems more appropriate.

Ilya.

On Wed, Dec 16, 2015 at 02:53 Vester Gottfried via swift-evolution <
swift-evolution at swift.org> wrote:

> I find myself writing the same else blocks for guard statements over and
> over again, so it might be reasonable to think about a default behaviour.
>
> In a current project I found 217 guard statements from which 183 have
> repetitive else clauses
>
> From which:
> 131 end with "else { return nil }"
> 44 "else { return }"
> 6 "else { continue }"
> 2 "else { break }"
>
> My proposal would be to make the else block optional and define a default
> behaviour.
>
> For example:
>
> func foo(x: Int) {
> ​    ​
> guard x < 10
> ​    ​
> ...
> }
>
> swift would implicitly add "else { return }"
>
> --
>
> func foo(x: Int) -> Int? {
> ​    ​
> guard x < 10
> ​    ​
> ...
> }
>
> swift would implicitly add "else { return nil }"
>
> --
>
> for i in 0..<10 {
> ​    ​
> guard i%2 == 0
> }
>
> swift would implicitly add "else { continue }"
>
> --
>
> switch {
> case a :
> ​    ​
> guard x != y
> case b :
> ​    ...​
>
> }
>
> swift would implicitly add "else { break }"
>
> --
>
> func foo(x: Int) -> Int {
> ​    ​
> guard x < 10
> ​    ​
> ...
> }
>
> swift would provide a warning that the guard statement needs an else block
>
> --
>
> Possible advantages
> - Less code
> ​ to write​
>
> - visually cleaner
> -
> ​ ​
> In code with multiple guard statements
> ​ ​
> you
> ​ ​
> would not have to repeat the else block
>
>
> Possible Disadvantages
> - Different behaviour in different contexts (func/return, for/continue,
> switch/break, …) needs to be learned and understood
> - programmers might forget that guard + else {} is an option
> _______________________________________________
> 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/20151216/e6f0249f/attachment.html>


More information about the swift-evolution mailing list