First of all, this ignores that for a number of reasons XCode is still the default IDE used by almost everybody (head over to the r/swift subreddit, and you'll see people talk about XCode apps/projects rather than Swift, for newbies it's not at all clear that there is a distinction), and that XCode isn't really that open to plugins and configurability. Personally, I'm using CLion (for server-side development), but it's far from perfect either, and I suspect that VSCode developers etc. will say the same thing; and even then, I can't get my team members to switch to my IDE of choice.
Second, this is not just about solo developers, but about mid-size to large teams where maybe a senior developer would like to make style decisions for the whole codebase that should then be adopted by the team in general; telling every developer how to configure their IDE in a very complicated way doesn't seem all that feasible. If there was some sort of widely accepted tool together with some tutorial articles à la "how to set up tool X with IDE/editor Y", it would be much better.
In my opinion, style choices that fall within a sane spectrum don't matter much, and consistency is more important. When it comes to conventions, I'm willing to sacrifice my freedom to argue about superficialities--I don't actually care where a brace goes as long as it's always in the same place so it can properly serve as a visual cue. I liken it to the standardization of manuscript and screenplay formats in the writing world, which are handled automatically by word processors so that everyone follows the same visual cues when scanning the page.
Agree there should be Official style guide and formatter for swift language. But i think there should be also a option to enable this enforcement or not. So that it can be backward compatible and safe for demo projects
developers are not, but corporations are, and for swift to be adopted more readily and reliably in corporations, a style guide or auto-formatter is important, because many large corporations need 1. coordination between teams and 2. hire lots ahem “interchangeable” team members.
————
my 2c is that i would prefer this to be able to be tightly integrated in the ide, that way as i type it’s already formatted correctly (pre-commit hooks in git is super aggravating and is the bane of my life... ) and format on save is also quite jarring...
This is why I think the solution is not to focus on style but rather on libraries for interacting with the AST. This is what an editor or IDE would need to be able to format and print code as it is input. This is also why I think the core project should own this tooling. To be great, it needs intimate connection to the language in a way that 3rd party tooling just doesn’t achieve. Any such libraries and tools will naturally need a default representation when printing the tree. So keep the default light and focus efforts on an interface that e.g. Xcode can integrate at a code level with so we don’t have silly pre-commit or on-save action hooks that rewrite entire files...
In addition to that and with regards to the following:
With the new Swift LSP transition that is underway I don't see what advantage the core project even has over any 3rd party tool that could be developed.
If all this means is enforcing the bad choices that Xcode makes for formatting, then no I do not believe it is valuable. 3rd party tools exist because Xcode is so bad. With that said, I do use Xcode formatting frequently for reindenting loops and if statements, but I cannot, in any circumstance, use it for a complete source file.
I hope this wouldn't enforce Xcode's bad choices. There's a lot of people that have gripes with Xcode's formatting. I think this would ideally be independent of Xcode since this would occur at the language level instead of the IDE level. It would likely function similar to the 3rd party tool; being a separate executable that could be ran as a separate build stage (or on file save or whenever).
But this is just a pitch and all this would need to be proposed and accepted first.
YES(to we can move on to the work )
As the same time I support to make it optional.
How do we ever know if it's good or bad if we never do it. But I know for sure it will save time and cost for people who know the pain of war of style(ego). So they can use the resource on something more important(etc. code design).
There is now an official review for this proposal:
Thank you to everyone who contributed to this thread in the pitch phase. That feedback will be incorporated into the final review. Note that the proposal has been revised based on feedback on this thread. Please continue further discussion on the review thread.
