Discussion: Closure syntax about swift-style-guide HOT 9 CLOSED

My vote is always for the simplest thing possible.

How should we format closures with parameters? A Sprite Kit example:

return SKAction.customActionWithDuration(effect.duration, actionBlock:
  {(node: SKNode!, elapsedTime: CGFloat) in
    // the actual code goes here
  })

I'm not very happy with this syntax (especially the line with the closure's parameters) but it's the least ugly thing I could come up with...

from swift-style-guide.

My vote is always for the simplest thing possible.

OK, sounds good

How should we format closures with parameters? A Sprite Kit example:

erm ... see above, the simplest form does not have explicit parameters :-P

from swift-style-guide.

Like this you mean?

return SKAction.customActionWithDuration(effect.duration, actionBlock: {(node, elapsedTime) in
  // the actual code goes here?
})

(For some reason this didn't compile for me earlier. It works fine now... Xcode bug, no doubt.)

Anyway, my question was more along the lines of, where do we put the parameters: on the same line, on the next line?

from swift-style-guide.

If using parameter names I like the idea of having the on a separate line, as it reflects the way that method are formatted.

from swift-style-guide.

Of course, this will also work:

return SKAction.customActionWithDuration(effect.duration) {(node, elapsedTime) in 
  // the actual code goes here
}

from swift-style-guide.

Of course, this will also work

Yes, that's the trailing closure syntax, and I really don't like it! Perhaps it is better for multi-line closures, which removes the need to end with })

from swift-style-guide.

This one is tricky. There are so many ways to do it. Again, in the session videos they seem to be bragging about cool stuff like $0, but I tend to think those types of variables make things less readable. I use them in scripts because I don't have a variable name, but otherwise, why not name it?

Of course, str.sort(>) is the preferred method for that particular call. You shouldn't define a new closure for one that already exists.

But in cases of our own closures, I am not so sure. This will probably come down to preference for a while until I've written and read more Swift code.

My first guess as to my preference is

a.func({ a, b in return doSomething(a, b) })

I think that is how most of the examples I've see have been.

Also, in some sessions they have examples like this:

a.func { a, b in
doSomething(a, b)
}

Not sure how I feel about it, but it does separate the parameters from the code a bit

--------- Original Message --------- Subject: [swift-style-guide] Discussion: Closure syntax (#4)
From: "ColinEberhardt" [email protected]
Date: 6/10/14 1:41 am
To: "raywenderlich/swift-style-guide" [email protected]

The Swift closure syntax is incredibly flexible. These are all semantically the same thing:
str.sort({(one: String, two: String) -> Bool in return one.compare(two) < 0}) str.sort({(one, two) in return one.compare(two) < 0}) // return type inferred str.sort({one, two in return one.compare(two) < 0}) // no need for brackets str.sort({$0.compare($1) < 0}) // shorthand variable and implicit return str.sort() {$0.compare($1) < 0} // sort has a single parameter, so closure can pop outside str.sort {$0.compare($1) < 0} // no need for brackets str.sort(>) // ok, not a closure, but > has the correct signature. Awesome! Should we recommend that people use the shortest form possible unless it seriously impacts readability?

Reply to this email directly or view it on GitHub.

from swift-style-guide.

I think first of all, we should always be using trailing closure syntax where possible. It seems like one of the most loved features of Swift by Apple.

I also don't like implicit returns, so I think return should be added whenever the closure expects a return value.

Other than that,

a.func { a, b in
doSomething(a, b)
}

looks pretty good!

from swift-style-guide.

+1 for the "simplest possible format other than numbered variables, with parameter names":

a.func { a, b in
doSomething(a, b)
}

from swift-style-guide.