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

[Ian Ynda-Hummel]

I am also +1 for implicit return, but -1 on continue/break for the reasons
already stated.

I'm -1 for removing braces for one-liners. I think maintaining braces
around blocks helps distinguish them from expressions. For example,

    guard x < 10 else return

would catch me off guard (pardon the pun).

I think I'm -1 on VoidLiteralConvertible, but I'm somewhat undecided. I
think that separating the return value from the actual return point could
lead to a lot of confusion, and would subsequently also make it easy to
accidentally return the default value when you didn't intend to as the
compiler wouldn't complain about a missing return value.  I don't think I
have totally convinced myself that the latter is a non-trivial problem, but
I thought it was worth mentioning.

On Wed, Dec 16, 2015 at 11:59 AM ilya via swift-evolution <
swift-evolution at swift.org> wrote:

> Actually I thought about VoidLiteralConvertible some more and now I think
> if we include it the only nontrivial case in the standard library case
> should be Optional.Nonel. Empty arrays and dictionaries are different from
> nothing, so it's best to always return them explicitly.
>
> Oh, and it would help with default values, e.g.
>
> var something:Something?
> // where does the default value come from? VoidLiteralConvertible!
>
> I want all default values for String in this scope be "none":
>
> private extension String: VoidLiteralConvertible { ... return "None" ... }
>
> On Wed, Dec 16, 2015 at 10:49 ilya <ilya.nikokoshev at gmail.com> wrote:
>
>> +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
>>>
>> _______________________________________________
> 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/060ce056/attachment.html>