What is your evaluation of the proposal?
+1 on the idea of having an official formatter; +1 on the idea of having a default style; -1 on having an "official" style (this distinction is subtle but very important) and -1 on this proposal because it leaves me with more questions than answers and more promises than solutions.
In short, -1.
In my opinion, the proposal focuses on supporting "one true style to rule them all" and omits the importance of extensive configurability (which is mentioned just once in the whole thing).
Is the problem being addressed significant enough to warrant a change to Swift?
No, it's not, for four reasons.
1. I don't see meaningful discussions about code style that often during code review (both in open-source and closed-source projects). If there are discussions, they are quickly resolved by author either adjusting to the project style or justifying the custom style they used.
2. Swift has a well-established and well-designed grammar. Modifying coding mindset to match the project style is not a very hard thing to do.
3. Tools like SwiftLint are more than good enough solution for linting and formatting.
4. In practice, code style emerges from the architectural decisions and frameworks used. A project based on FRP framework (such as ReactiveCocoa) wouldn't and shouldn't use the same style as a project based on vanilla UIKit.
Does this proposal fit well with the feel and direction of Swift?
No, it doesn't, for two reasons.
1. Up until this proposal, Swift was marketed as an easy to learn language and expressive like no other language before.
Introducing an official style would render those two features obsolete. I don't accept the argument of it being "optional". In my opinion, thinking that there would be no pressure to adopt the official style in as many projects as possible is naive.
If this proposal is accepted, I can already see recruiters refusing to hire a developer because they don't follow the official Swift style. I can see teachers giving lower marks because there should be no space before the colon. I can see teams agreeing to ditch using a custom style in a well-argued case just because it would deviate too much from the official one.
2. This proposal is a poor proposal, in general. It doesn't present any concrete solutions to the problems it lists, especially regarding configurability. And it doesn't come with a pull request.
If you have used other languages with a similar feature, how do you feel that this proposal compares to those?
I used many tools which do linking or formatting or both: SwiftLint, ESLInt, StandardJS, Rubocop, PyLint. All those tools (except StandardJS) have one thing in common: they're configurable like crazy. This proposal doesn't remotely match that.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the proposal and read the pitch thread until it blew up and was impossible to follow anymore.