Inferred return for guard statement

[benrimmington]

[Pitch] Allow alternate version of 'Guard' with 'Guards'

Proposing an alternate of guard named guards that implicitly returns out of the function and would supply nil if an optional return was declared. This would be purely for the sake of brevity yet still allow for the more explicit guard version to be used. example: guard requiredObject != nil else { return } or guard requiredObject != nil else { return nil } becomes: guards requiredObject != nil but still allows for: guard requiredObject != nil else { // track analytic event or log case …

An implicit return for guard

Dear community, While using ‘guard’ with much appreciation, I noticed a few cases where I would of hoped for better and more concise code. As of now, you receive a compiler error if your guard statement does not provide an ending statement such as return/break/etc. at the end. It is informative, but in many cases such a statement makes the code repetitive and less concise. As an example of cases where there are multiple guards done sequentially to avoid very nested and unclear ‘if's: gu…

Guard Implicit Fallback

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 ha…

Proposal: Add implicit/default else-behaviour for the guard statement

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 < …