Strong +1.
Yes!
Yes.
Yes, Python's PEP-8 and I love it.
Read the pitch and the proposal.
We are also willing to consider additional degrees of configurability.
On what basis will these be considered? Is it based on personal preference, accessibility, practicality of screen size, etc?
+1
I strongly believe the style guidelines and formatter should be mandatory, à la Go.
4 Likes
+0. While I always welcome better tooling support, the wording of the proposal tilts away from “common/default style” to “official style”, which is a big deal to me. There’s nothing wrong if 60% of the community decides to standardize on a common style, but I certainly don’t want to see code that doesn’t conform to the decreed style start to be considered illegitimate.
No.
(I’m also curious that 7 people, mostly new to the forums, came here to vote in favor of this within 30 minutes of it being posted?)
N/A
Python has this, but python is also a much simpler language syntactically, so I would hesitate to transfer assumptions between the two languages.
Participated in discussion and read the proposal
8 Likes
Do you mean the other way around? The new version of the proposal was updated to specifically avoid phrases like "official style guide" in order to address the very sentiment you're expressing here; we don't want anyone who has different needs/preferences to feel "lesser" but we still want them to be able to benefit from the tooling.
The proposal text seems to imply that “not mandatory” means “the compiler will still compile code that doesn’t conform to the guidelines”. My gut feeling is that “official” will become an unspoken part of the proposal, and after a while people are just going to start calling the recommended guidelines the “official guidelines”. It does not help that many of the voters supporting this proposal are using language like official and mandatory in place of the actual proposal language. It should be updated to specifically emphasize that any such guidelines would be
- default guidelines, not standard guidelines.
- common styling, not recommended styling.
“recommended”, “standard”, and “official” carry v different implications compared to “default” or “common”, and a responsibly-written proposal should make that clear to avoid anything getting ratified de-facto that isn’t in the actual text.
6 Likes
We strived to clarify as much as possible from the previous iteration of the proposal based on the wealth of feedback in the pitch thread, with statements like this which are intended to clearly explain our position on the matter:
The use of "recommended" elsewhere in the text was deliberate. We do wish to "recommend" these code style guidelines just as Swift recommends the API Design Guidelines. That doesn't mean that people can't diverge from those if they have good reason, where "good reason" is honestly whatever they want it to mean for their project. If someone working on a personal project wants to do something completely different, great! We have no interest in stopping them or dictating anything to them.
There's nothing we can realistically do to prevent all possible misinterpretations of the text no matter how explicit we try to make it, and people will interpret words differently no matter which ones we choose. Ultimately, the proposal text has to be locked down at some point and I hope people will review it as it is written, not based on how people might hypothetically misinterpret it.
13 Likes
-1
Imho the proposal is neither one thing nor another:
It won't ensure consistent formatting of Swift code, and still, it would repell people who disagree with the choices made in the guide.
It's just not possible to get the best of both extremes (staying neutral vs. enforcing a single style), but it's very easy to get the worst combination.
Looking at this forum, I predict that acceptance will only lead to a myriad of endless discussions, which burn time which can be spend better.
Btw, afaics, the proposal isn't even qualified to be reviewed unless the Evolution process is changed so that an implementation isn't required anymore...
10 Likes
Part of the proposal is the adoption of a formatting tool into the Swift project, whose implementation is linked in the proposal: https://github.com/google/swift/tree/format
2 Likes
An agreement is what everyone walks out of the room feeling like they agreed to. Any organization is governed by the people in it, not what’s written on a piece of markdown. Based on the reviews so far, it seems like most people are agreeing to an official style, not a default style.
Huge +1. And a big thanks to the proposal authors and everyone who contributed to SwiftSyntax and the swift-format tool.
Even if this doesn't get accepted (which would be sad IMO), I hope that swift-format is open sourced separately so that those who want to benefit from it can.
4 Likes
+1 on a default or official style guideline + integration of such a tool into Swift.
It would solve so, so many counter-productive problems when working in large projects or with many developers.
Coding is hard as it is, so let’s make it a little bit easier. 
2 Likes
Fair, the position is clear, not disputing the clarity (just that it may be rubbing people the wrong way as the resistance is about exactly that... people may not be desiring an official Apple/ Google blesses code), but based on this I think having better tooling support so that Xcode plugins and command line tools could do the formatting job better and more easily may be a better win for the community than trying to bikeshed the “recommended” style and the repercussion it will have in the daily work life of teams... how minor or major they may be depending on the people and the team culture.
It is interesting to see if this would have any effect how many people would maintain other tools like Nick’s swiftformat, swiftlint, and others with a blessed 1st party tool on the market... unless like SPM vs Cocoapods or Carthage it cannot be used yet for some reasons (with SPM being it not being easy to use / supported for iOS projects yet).
Depending on the changes that will make your Swift-format tool be able to do its job and the other formatters being able to benefit from it or not it would be a -1 to +0.5.
1 Like
I'm really thankful for this work, and I very much support having linters, formatters and similar tooling — but I can't see the benefit of "blessing" a particular tool.
Actually, I think this won't actually help, but rather slow down development.
4 Likes
+1 on having a built-in, works out-of-the-box formatter that ONLY uses the recommended style (just like the highly liked gofmt utility), but -2 on having a style guide that is not mandatory.
Overall, -1.
If the style/format is not mandatory, then why even bring it to the table for discussion? I feel like only the people that will use it are those who agree with all its decisions or those who are forced to use it in order to contribute to swift. The proposal states as much when it says:
A tool that is not configurable only works for users
who are completely satisfied with the defaults.
That quote is specifically talking about making the formatter configurable, which I also disagree with.
If there's just going to be another configurable formatting tool then I am strongly opposed to diverting more resources when there are perfectly capable tools already out there. Those who really care will find them, install them, and configure them. Those who don't care won't. I really think it's just that simple. The current status quo is a valid thing to consider.
I know that if I'm not forced to change my coding style then I certainly won't bother with it. Sure there may people who end up referencing the recommended guidelines as though they were official guidelines, but the majority of users will likely never need to even know about the recommended style if they don't absolutely have to follow it.
The proposal states:
We have chosen not to do so given that Swift is a well-established language.
I don't think that it's "too late" to have a mandatory style guide just because swift isn't a new language. There have been plenty of changes that resulted in widespread fallout that were done regardless and I wouldn't be surprised if there were further changes in the future that resulted in significant changes/breakage. Much of this has been/will be done in a multi-phase deployment. ie: begin with deprecation warnings in the next version, then in failures with the following version. I see no reason why this couldn't be the same. Start by warning people that their code doesn't follow the "official" guidelines. Then in the next version make it a compilation failure.
Also, if there's an associated formatting tool then it would automatically convert everyone's code to the recommended format anyways right? So why couldn't we make it an official/mandatory guide? Going forward there would be a learning curve while everyone adjusts to the changes, but it wouldn't take that long for everyone to learn/accept them.
Without the format being enforced I view the meat of the proposal as being about making a "blessed" formatter. No one really cares if the backend is built using the new SwiftSyntax if it doesn't work as well as the competition. SwiftFormat is 3 years in the making and a new tool would take years to catch up to where it's at today, regardless of what backend powers it. I restate my opinion from the pitch phase that the people who really care about enforcing their preferred style are going to evaluate the tools available and do whatever it takes to get it installed/configured to their liking.
Yes. The motivation stated in the proposal is entirely valid, I just disagree with the proposed direction.
I'm on the fence here. While swift is opinionated in some aspects, it largely tries to let people do things how they want to do them (however horrible that may be). I think it would be nice to have an "official" (not just recommended) style guide/best practices. Whether or not this is something that swift should become opinionated about is not something I feel qualified to say.
I use PEP8 formatting tools when coding in python and the gofmt tool is highly liked. I wish swift would make the leap to require an "official" format for all the reasons why this is being proposed in the first place. It's a real pain to read different code soemtimes. Consistency is a really nice thing and I'm willing to sacrifice my own preferences to make it easier for anyone to read swift code anywhere.
9 Likes
If the discussion is over because the tool admits no configuration or very limited configuration options perhaps, although people will be frustrated anyways (they will just not be able to do much about it...).
If the tools is configurable, see the great swiftformat by Nick Lockwood (it is a different tool than the one presented here), then people will still argue about how to configure it.
6 Likes
From Twitter probably - that’s where I came from. Also a tiny hint of a glass ceiling there? 
This is a topic I as a professional Swift developer feel very strongly about and where I really want to make my voice heard.
Personally I wish I’d have the time to engage more in other evolution proposals too, but the time just isn’t there.
18 Likes
- What is your evaluation of the proposal?
+1 - Is the problem being addressed significant enough to warrant a change to Swift?
Yes - Does this proposal fit well with the feel and direction of Swift?
Yes - If you have used other languages with a similar feature, how do you feel that this proposal compares to those?
Good - How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Careful reading
-
What is your evaluation of the proposal?
+1.
-
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, trying to enforce a coding style to be used consistently throughout a project is tough, and having a blessed way to do this (assuming it will be integrated into Xcode) would be a big help.
Before somebody asks, "Why not just use a community tool?" besides them not being comprehensive enough in my experience, it's much harder to get people to bother installing and configuring a community tool, compared to a blessed formatter which could be as simple as ticking a checkbox, or would be enabled by default.
-
Does this proposal fit well with the feel and direction of Swift?
Yes, part of Swift's charm is it's clean syntax and readability. Working on projects that have multiple people working on them who sometimes fail to follow the agreed coding style harms that. Having a blessed formatter will be helpful, even if it's opt-in/opt-out.
-
If you have used other languages with a similar feature, how do you feel that this proposal compares to those?
It will bring parity to them. I have used the formatter in Android Studio and Xamarin and it is a great relief not having to worry about manually following a coding style. I can write it however I feel at the time, and when I press cmd+s to save, everything is formatted for me, I don't even have to think about it.
-
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the draft, the proposal and discussion and noted my experience using formatters for other languages.
-0.5, for very similar reasons to @Ponyboy47.
If there were specific configuration options that are for accessibility or purely practical reasons, I would understand that being there.
But if this tool allows configuration just for preference I see no reason why it should be an "official" tool in any way. It's just like other tools like SwiftFormat, except it has less functionality. It also won't achieve what was previously a goal of having consistent styling between projects.
I think this has some validity do it, which is why I went -0.5 instead of -1.
We have chosen not to do so given that Swift is a well-established language.
If it can be controlled to just reformat code on a file you've touched, I don't see the problem (or just convert all of it in one go using the command line tool).
Yeah, I don't think it's a big issue but it's worth addressing.
I don't think this has anything to do with Swift itself.
I've played with gofmt and talked to other people that do it more regularly than I. They all seemed to like the consistency.
participated in discussion and read the proposal
2 Likes