+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.
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.