That's not a matter of style or formatting. It is a matter of correctness of code; enumerated() does not return indices.
...and therefore it is a matter of style and formatting. One of these is idiomatic, and the other is not; there is no reason not to standardize and thereby eliminate the matter altogether.
Yes, indeed, style and formatting are issues that people deal with. Most of the readers and writers of code are people, not colons.
Right, this is what a linter is for.
I have no problem using different conventions depending on the language I'm writing at the moment. For example, the Allman style prevails in the C# world. These conventions are a useful flag for me to adapt my thinking to a particular language.
As a result, I'm in favor of a style guide and formatter for Swift. Speaking only for myself, configurability isn't a concern--if the default style differs from the code I've written before, I'll update my personal style to match.
Your first example feels more like the realm of a linter. It would be awesome to have a officially supported linter 
but this is a different discussion. The formatter should only bother about whitespace characters and has value in its own right.
I find @xwu's point about keywords a very good one. What about the (imaginary) vocal minority that are using custom preprocessors in order to use fn instead of func? Is it pure imperialism that func has been set in stone and there is no configuration option to change it? I'm sure they have very good reasons to prefer fn over func.
well, i suspect a lot of people use them interchangeably given poor knowledge of Swift’s Sequence/Collection hierarchy, and when used on Arrays, they are interchangeable, so it is a matter of style in that context. Those of us who use generics prefer zip on indices for consistency between Array and ArraySlice, but ultimately that is a style preference, for Array loops, since the code is functionally identical. But this is all very specific and not really relevant to the thread so i’ll stop.
not to shade the effort here at all, but in the spirit of standardization, it’d be nice if we had the same enthusiasm for standardizing currency/textbook types like RGBA, Vector, Matrix, Quaternion, Queue, RBTree, etc. Who’s in? (on a different thread of course)
well, count me in for the linter effort <13
i honestly probably will not use this style guide or formatting tool, though i have no objection to it being organized here. I (like others) just ask that we call it the Default style guide and not the “Official style guide” to emphasize it as a starting point rather than a prescription.
I believe the formatting tool that comes with it should be customizable, but customizations should not be called ‘Default style’, in order to maintain the standardization and consistency (and thus the whole point) of the default style rules.
In other words, we should not have a default-style-formatter, but rather just a style-formatter that is capable of applying the --preset=default style, along with downloadable, team-defined, and user-defined presets. I suggest this only because I suspect much of the code implementing a default style formatter could also be repurposed to apply other styles, and offers a win-win between those who want to preserve the uniformity of the default style, and those who want to use their own presets.
this is a pretty out-there example. i don’t think anyone is going through the effort to preprocess fn to func just so they can spell function declarations differently. I only recently bothered with getting an automated gyb preprocessor up and running in one of my build systems. Varying colon styles on the other hand are very much a thing.
What I do not understand, and would love to see answered by someone in this camp, is why posters in favour of a configurable tool believe that there should be an official language formatter.
As far as I can see, the desire to make the linter configurable boils down to a sentiment of "I am in favour of automated style enforcement, so long as we enforce my style". And that's fine, I get it. But if you want that today you can already have it: there are many Swift style tools already in place, as well as the new one proposed here. This is already the status quo.
What no-one has clearly elucidated in my view is why it is useful to have an official tool that does not have opinions about what the code should look like. So my questions to anyone in favour of a configurable official tool is simple: what utility is provided by such a tool that is not provided by the open source ecosystem today?
To me having a pationate preference over func foo() vs fn foo() seems much more substantial than let x: Int vs let x:Int. Why having one not be configurable is ok, while for the other is a travesty?
because fn foo() has never compiled with swiftc, whereas let x:Int has always compiled with swiftc.
So can I count on your support for my pitch to make func keyword configurable?
That would be absurd right? Why make people have to choose over 2 different styles?
If func and fn had been interchangable since, say, 3.0, then i would, but they’re not, so i won’t.
These people who look for an authoritarian single style should get together and create a tool and use it among themselves. Please stop your efforts to take away my freedom and force your opinions on me. Seriously. What is this discussion.
There is another way to look at those two opposed forces.
For each configuration option you add, you multiply the number of configurations the tool has to support. This combinatorial explosion makes the tool output less predictable, and the quality of the code it generates more difficult to assert, maintain, and preserve in the long run.
A sufficient amount of work could overcome those difficulties, of course. But we need some people to actually provide this work. This question is at the root of the configuration debate. It's still very abstract at this stage. It will become more precise sooner or later.
I'll personally push for the highest possible Quality. If configurability has to suffer on the way, I personally do not care. This is my point of view, I am able to defend it, and I am sure I will find support. And I do not have anything against configuration itself.
If this formatter turns out to be either intentionally crippled or seriously limited because of implementation complexities for which not enough effort can be mobilized (because of people who actively work against it because of their religious belief in mono culture code style) then this whole effort will be end up as a really sad story.
I love this pitch, and I also love this discussion.
Initially, my thought was:
Great idea, guidelines will be most welcome - they could at the very least be used for inspiration. But if a tool is made it should be customizable to my needs.
After reading a lot of arguments in this thread, I now realize that my own style and company style are still just arbitrary choices (helped along the way by great tools such as SwiftLint).
The purpose of these styles are readability and consistency.
If an official style guide and accompanying tool would impose a style on me - with no or few options for configuration, I would be just as happy (once I adjusted to the style).
So now I am totally on the side of those who argue for a common style. The fewer choices I or my team have to make, the better. 
There is already a tool with many configuration options that you can use today: GitHub - nicklockwood/SwiftFormat: A command-line tool and Xcode Extension for formatting Swift code
Or not, you are free to exercise your freedom of ignoring it. Even gofmt is completely optional, I'm sure Go programmers exist that are sticking it to the Man and are not using it.
Nick, thats my point: I hope we all will not be limited in our options to "one size fits all" vs "ignoring it". I hope we can have a powerful tool that is fully integrated and officially supported for all of us.
And as for the Go reference: If Go had more complex syntax - like Swift has - and legacy APIs with sizable function signatures - like Swift on Apple Platforms has - it surely would be a different story there, don't you think.
I know from experience with Dart that even though autoformat is obviously often super nice (like the one AppCode had when i used it years ago) there a significant amount of situations where the autoformat in Dart just fucks up the readability of your code.
Why? What would be different in this hypothetical to using SwiftFormat today?
Plus the fact that it is different to have "nothing" vs "this useful 3rd party tool, even though its not fully integrated" vs. "the official tool" that provides the "default style" most likely being nicely integrated into the tooling vs "this other 3rd party tool that people used before the official formatter you can still use if you really want" (or "stick it to the Man, as Nick put it so colorful : )
Adding: To make it clear what my idea of a good solution is: Everything i said before plus obviously having an officially announced preferred default style that is set as default setting BUT can be super easily changed to "OtherCommonStyleB" configuration and "Custom" with everything that IntelliJ IDEs offer plus anything else we might want.
And i don't see a good reason and have not heard a convincing argument to not aim for that.
If we want formatters to be nicely integrated into the tooling, we can do that without requiring that Swift ship a formatter. If we assume "the tooling" to mean IDEs and the swift command line binary, then I have good news. If a formatter places itself on your $PATH with a name like swift-format then the swift command line binary will automatically treat it as a sub-command implementation that can be run by swift format. For IDEs, the usual place to provide formatters is as a save hook: any hook in an IDE that could run an official formatter can run an unofficial one.
What no-one has laid out is what the specific advantage is of having the Swift project ship a configurable formatter that has not been addressed by third-party formatters. Let's use your follow-on paragraph:
Why is this better than having one, non-configurable default formatter, and then the currently existing open source ecosystem of alternative formatters? What benefit is obtained by having the Swift project attempt to serve all masters by providing a complex tool that supports arbitrary configuration flexibility?
The tool that you suggest (whose feature scope is "anything else we might want") is a profoundly complex beast. It provides only one utility over my counter proposal to just use a different formatter, and that utility is that "everyone runs the same command in their shell". In a world where we have invented symlinks, I don't find that advantage compelling.
So let me ask again: what specific, concrete advantage is provided by Swift shipping a configurable formatter, vs relying on the open source ecosystem to handle this problem?