That is a very good question. My understanding was based on @allevato’s comments and posted links, the read‐me file, the repository’s
Documentation subfolder, etc. The directory you found makes it look like there is far more implemented than the documentation implies, so maybe I was wrong. @allevato, do you have clarification?
That is Google’s internal style guide for its former Swift for TensorFlow project and not directly connected with
swift-format or this proposal. (Though due to stemming from the same company, it does probably describe the style the authors of
swift-format are most accustomed to.)
Since that style guide has been brought up, I will share my thoughts about it—but only in an abstract sense that informs on what the general scope and philosophy of the proposed style guide should be. Largely I agree with Google’s style guide. The parts I dislike fall under two classes:
Rules that do not make sense for a code base not written in English (such as the ASCII recommendation for identifiers). Such a rule makes perfect sense for a company whose working language is English, but not for a company whose working language is Chinese. It would get annoying fast if the formatter flagged warnings for this. However, a more abstract rule that lets the project configure its preferred set of characters would be welcome, since neither team likely wants Russian letters sneaking in and vice versa. Since participation in these forums is largely dominated by the English language, I am a little worried that the developer communities who code Swift in Portuguese, Japanese, etc. and have less voice here will end up with a tool working against them in these sorts of ways. I hope that outcome can be consciously avoided by review managers.
Rules that are at odds with Xcode right now. For these, I really don’t care which style it is, as long as it is consistent. But it becomes annoying when the various tools are fighting against each other. This point is actually in favour of the proposal at hand though, since it would help resolve the disparity in one direction or the other: Xcode would adopt the standard style†, or the standard style would adopt Xcode’s way. Either way, problem solved!
†Bonus points for a standard configuration file that Xcode and other tools can all read and obey, like how any tool can read a package manifest using the SwiftPM package.