I'd like to defend the standard library style (purely as an observer/user, since I'm not on the Swift team and had no hand in creating it) 
. It's definitely something of an odd divergence from usual styles when you first see it (the first time I saw ) { occupying its own line, I was taken aback), but it actually has some quite nice properties that enhance readability and structure.
In fact, at Google we've recently based our own style guide on it. As we use it on more and more of our code base there are still some edge cases to shake out, but it's worked quite well for us so far.
The main property of the stdlib style that I like is that it tends to create logical visual groupings when a declaration needs to be wrapped. Since the stdlib deals heavily with generics, this matters a lot when you have, say, a function that includes a number of generic arguments, regular arguments, and generic constraints:
public func computeSomething<
Sequence1: Sequence,
Sequence2: Sequence,
Result
>(
_ sequence1: Sequence1,
_ sequence2: Sequence2
) -> Result
where
Sequence1.Element == Sequence2.Element,
Result == Sequence1.Element
{
// do some things
// do some more things
}
Some folks are surely bothered by things like the angry-looking >( line, but that can be very easily scanned visually to see what the different parts of the declaration are.
Conversely, the more common line wrapping styles in this case would do things like put the argument after the first parenthesis and then align the others underneath it. That creates "zig-zags" throughout the code because that indentation changes depending on the length of the function name or expression that came before it. You have to scan both vertically and horizontally to find what you're looking for. In stdlib's style, you only scan vertically—the arguments are always +2 from where the function started. It's consistent.
This leads into another big advantage, and a topic of this thread: that style more easily lends itself to being automated, because the set of constraints you need to optimize over shrinks quite a bit. When you discover that a declaration needs to be wrapped, you don't need to factor in the length of certain things that came before it (like the function name) in your later computations, which then affects whether and how you need to wrap those remaining lines. You just bump yourself in +2 and continue your work. This reduces the number of situations where you have to backtrack and try to find a wrapping that still fits within your column limits.
As an example where this matters, consider that each argument in a Swift function has three parts—label, formal argument, type—where languages like C and Java only have the latter two. In addition to that, Swift's API naming guidelines encourage that the function name and those labels form a fluent phrase when possible, and that tends to increase the character count of those compared to other C-style languages. The standard library style gives you as much room as possible and handles that situation very elegantly.
And yes, we've been lucky to have @harlanhaskins working with us on some tooling related to these problems! We're looking forward to showing off the progress we've made soon and getting the community involved in its further development.
now it's fixed