Modest Swift 5.1 updates needed

[rayfix]

These come to mind:

1. Single expressions of return should elide the return keyword. I think this keeps with the spirit of minimalism in the current guide and is what the Swift Apprentice and Swift Algorithms books have adopted in the coming new editions.

2. We should probably solicit feedback from the SwiftUI book authors for best practices on formatting body function builders.

3. Prefer use of Self instead of the explicit name of the type when possible.

[ondrejhanslik]

I am not sure avoiding explicit return is a good advice in general. I would recommend the same I am using in other languages - avoid return only in single-line closures/functions. Not in single-expressions.

e.g.

override var myVar: Int { 10 }

but

override var myVar: Int {
   return 10
}

or

let element = array.first { $0.isValid }

but

let element = array.first {
    return $0.isValid 
}

In my opinion, that's the best for readability. I am reluctant to omit a keyword just because it doesn't have to be there.

[hollance]

override var myVar: Int { 10 }

This is not a useful example, in my opinion, because you wouldn't often write that in a real program.

While the second example is not new; we've always been allowed to drop return in closures and I don't think the multi-line version with return is very common.

[marinbenc]

I think we also need to clarify, when writing a SwiftUI body, which method calls should be indented and when. For instance:

Button(action: buttonPressed) {
  Text("Hello!")
    .padding()
}.padding()

vs

Button(action: buttonPressed) {
  Text("Hello!")
    .padding()
}
.padding()

Likewise, I'd suggest we advise to always split button actions into specific methods, so they don't clutter the body.

There should probably be a lot more SwiftUI specific standards.

[rcritz]

@marinbenc tell me more about your feeling on splitting button actions into specific methods. The idiom seems to be to put a closure there, but that will flag with SwiftLint with the raywenderlich.com ruleset. Doing as you suggest gets rid of the flagging, which is good. But I hesitate to make that a style guide requirement.

Oh, and the second form you show above is the correct form. The first will flag.

[rayfix]

@rcritz @marinbenc Hi! Multiple trailing closure syntax is coming in Swift 5.3 which will undoubtedly be released during WWDC20. I think it will look something like this:

Button {
  Text("Hello!").padding()
} action: {
   print("Hello tapped!")
}
.padding()

Notably, this has been added to the API Design Guidelines:

Name functions assuming that the argument label of the first trailing closure will be dropped. Include meaningful argument labels for all subsequent trailing closures.

See:

https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md

[marinbenc]

I agree that probably moving functions out of body and into methods is more of a case-by-case type of thing, so probably shouldn't be enforced by the style guide.

[NikKovIos]

I disagree with excluding return word. Understanding is preferable that minimalism!