I do not care about the "Swift project shipping" it part. I do care about a) configurable b) integrated c) officially supported d) having it as an accepted practice in the community to use it that way and not being labelled a fringe thing for people who intend to avoid the officially endorsed "normal way".
Thats basically it.
And by integrated i don't mean getting a 3rd party tool from GitHub, hooking it up in one of 5 different ways, editing config files. Putting files in $PATH, etc. In the year 2019 it should be integrated into the IDE just like you want powerful refactoring and debugging tools inside the IDE. Imagine asking for refactoring in Xcode and being told you should just install this helpful tool and do this bit of configuration work and every time do 3 steps to refactor something instead of just pressing a key and getting a sensible context menu. No way, right? For people who prefer or are forced to live in the terminal there should be a way to run it from there, obviously.
What does "officially supported" mean if not "shipped by the Swift project"? For that matter, what does "integrated" mean if not "shipped by the Swift project"?
Regardless, I understand your argument. Fundamentally the tool you want is something close to what mix can do for Elixir, though I think mix is not quite configurable enough for your goals. Alternatively, more like rustfmt but provided by the language.
I think if the Swift maintainers and @allevato's team are happy supporting something like rustfmt, that's great, go ahead. We'll use it, set to its default settings. I just want to note that I think many people in this thread will be disappointed by that tool: the odds of it supporting the quirks of everyone in this thread are approximately zero.
Given two completely interchangeable things A and B, if Swift supports both today, is it your opinion that Swift should never prefer or encourage one over the other in any way? I am not sure how you are in support of any style guide or formatter in any form then.
@taylorswift may not be interested in the style guide, indeed, but may still be interested in the formatter as a way to enforce personal customs and traditions.
Sure. Keep in mind, however, as @lukasa has said, that "the odds of [the formatter] supporting the quirks of everyone in this thread are approximately zero."
I don’t think anyone is arguing for this. The default style would in fact be very opinionated. I suspect most of us would prefer to stick close to this default style, but there will inevitably be some decisions it makes that we don’t want to be pinned down on. The specific decisions and rationale for wanting to deviate from the default will vary from project to project.
The existing open source ecosystem provides some excellent tools. However, it cannot and will not ever set a baseline in the form of a default style that is shared by the entire community. Further, the defaults that do exist in these tools have been chosen by their authors rather than discussed and reviewed here on SE.
Aside from defaults, I also believe there is merit in having a standard tool that ships with Swift. This means it is available to all Swift projects with no additional downloads, maintenance, configuration, etc. This is a nontrivial benefit which increases with configurabilty because it would be applicable to more projects, including those that are unwilling to follow the default style 100%.
That said, I think @nicklockwood’s concerns about this tool not receiving the attention it deserves are valid. Done right, an official tool would channel the community’s energy and therefore be of higher quality than could be achieved via independent competing open source projects. Done poorly, a standard tool would be unfortunately limited relative to competing open source projects but would zap the energy and motivation to continue developing those tools.
I think it’s important that if we do tackle an official tool we are committed to doing it right. Realistically, that means the organizations that propose the tool should be willing to commit to investing the engineering resources necessary to do so. It must be a best-in-class tool by any reasonable measure. Anything less would be harmful.
Yes - we usually avoid talking money or time share or Xcode team in those forums, but it is quite close from the surface in this thread.
In this regard, we can compare the Swift formatter to SPM. A big ambition and a crowd of developers hungry for it, but slow to deliver and change everyone's practices. Please take no offense: SPM is alive and moving.
The lack of any information about resource allocation makes it actually difficult to discuss the Swift formatter. For example, of course I'd be happy to support as much configurability as possible. But if this project is as gifted as SPM, I'd rather avoid any kind of configuration, and focus on a minimum viable product. This does not make the task easy for you, @allevato
If this project is resourced similarly to SPM I’d rather avoid the project altogether and just continue on with the tools we already have. It would still be possible to document style guidelines just as we have for API design guidelines. We could even provide configurations implementing these guidelines for popular open source formatters. But I think an official-but-resource-crippled formatter project would be harmful even with an MVP focus. The harmful effects derive from its mere existence as an official, but subpar, tool.
I'm certainly more optimistic than you are. What you call a "official-but-resource-crippled formatter" may be a wonderful tool that does one thing and does it remarkably well.
Perhaps, but it could also do the same thing in an unofficial capacity without the risk of harming the energy going into the tools we already have that meet other needs. What is the motivation for making it an official tool if we do not intend to provide resources to make it a tool that meets the needs of most Swift users in its domain (formatting in this case). IMO "official" tools should be intended to meet the needs of most users and should be resourced accordingly. If the resources are not available, what's the rush to declare it "official" and have it ship with Swift?
I think one part of this discussion that might not be getting enough attention is that everyone probably has a different definition of "configurability" when they say "the formatter could be configurable." But it's not a binary choice—it's a spectrum:
A rigid and unconfigurable tool that ignores any user-provided whitespace except for the minimum required between adjacent tokens, essentially converting code to a single canonical form
#1, but respecting user-provided discretionary line breaks so that the user has some control over readability with regard to line wrapping
#2, but allowing for adjustment of a limited set of configuration options for practical reasons (like line length or indentation size, since some IDEs have constraints when working in multi-language projects)
#3, plus some additional but still limited set of options
A tool that allows users to configure literally every decision it makes regarding where to place a given token.
Folks so far have spoken up in favor of just about each of these, so it's not quite as simple as "should it be configurable, yes/no".
Obviously nobody can predict the future to a perfect degree, and I personally can't make any statements on behalf of Apple, but I can say that my team at Google (who builds our Swift support for Bazel and has made numerous contributions to parts of Swift) is committed to continued support of our tool. It has a large user base here so that alone is motivation to support it, but we would also not propose simply throwing code over the wall and calling it a day.
This is oversimplifying the problem space quite a bit. It requires that:
Any tool that wants to hook into this provide the same command line interface, and possibly the same minimum configurability characteristics
It presumes that the owners of those environments are willing to or able to provide those hooks
It ignores the possibility that those environments may want to do formatting in-process instead of spawning an external process, in which case you now have a resilient API design problem instead of a launch-an-executable problem
It also doesn't solve some of the original motivations, one of which is to provide a solution for the average user who just wants a common problem solved for them without having to seek out, evaluate, and configure alternatives.
I think in some ways there's a power-user bias; those who want to configure things exactly the way they like them are probably going to be disappointed by any solution we could present here. They're free to use something else if they wish, as is their prerogative. But that's not the only audience that we need to consider. There are a large number of individual developers, teams, and companies who want something That Just Works™ and performs reasonable behavior (either by default, or by design) without adding numerous extra steps to their developers' setup workflow.
Absolutely, which makes it difficult to evaluate whether we like the pitch or not even with a concession to configurability. I probably fall somewhere into camp #4 but that depends on what is and is not included in the "limited set of options". That said, control over line breaks, line length and indentation gets us pretty far. As mentioned upthread, I think it would be acceptable to omit configurability on style issues where there is a clearly dominant style in the community. (Which of course begs the question how do we determine what is "clearly dominant" - on that topic I don't have an immediate suggestion)
To be clear, I agree. I'm not proposing a "magical super tool": I'm in the camp of wanting zero configuration in the default tool. However, I also think that if users value flexibility they should demand that of their IDEs. Power users are capable of configuring their IDEs: developers that want "Just Works" get a tool that is highly likely to work because it does not have the burden of configuration management code.
This thread has changed my original mentality and I am now opposed to making a "default" style guide unless it is the "official" style with an accompanying non-configurable tool. After reading through every single post in this thread, I believe the overwhelming majority of people who have posted here have either stated strong support for a non-configurable tool or have stated that they like configurability, but would just get used to having a single supported style.
I get that having one automatically integrated into the language would be nice, but adding something to your $PATH really isn't hard (most installs automatically add their executables to a $PATH location anyways) and configuring something in your IDE isn't either (almost all IDEs support the kinds of plugins/hooks this requires). If you want a configurable tool then you're going to be configuring stuff anyways so is requiring one or two extra steps of configuration really asking too much?
If you want a configurable tool, you already have several choices. They just require some configuration...which is what you want anyways isn't it? This is coming from a frequent user of SwiftLint where all my swift code is run through the linter automatically when I compile my projects.
I would disagree. All the hook really needs is a command line interface. How many IDEs supporting hooks like this really care how the command works? They all just require a command to call. Most allow you to even specify the arguments for the command in the hook configuration. Or if your command supports a configuration file, then you just need to make sure it's in the right place and has the proper name.
I would add that I doubt the average user wants to do any sort of configuration, and what's the point of a configurable tool for the average user that will never configure it? If we really want to actually help the average user that just wants to write code and not worry about style, then make an "official" style guide and non-configurable tool that will handle the style for them. If the average user doesn't want to learn how to configure a 3rd party tool, then why would they care about configuring the built in tool? Why make another competing standard? (Sorry for linking to the same comic twice)
Or we could just do nothing and let them write code however they want. Who says they even need a style guide to do that? That's where we're at currently at it seems to work just fine. I see no reason to push for yet another configurable tool when there are already several alternatives. If you don't care enough about having a style guide to follow then you're not going to learn how to configure the built in tool and there's no point in making it configurable. If you do care enough about having an enforced style guide then I bet you're going to go out and evaluate all your options to determine the right tool for the job.
I fear that the few exceptionally opinionated on both sides may overcome the majority of people who really don't care enough to fight either way. If it's configurable then they'll use it. If it's not then they'll live and get used to it.
Most people like to code the way that feels natural to them, but are not so dependent on their own style that they couldn't become accustomed to a new one. I am in that same boat. Many people also feel that having a non-configurable tool would eliminate much of the personal preference fights that occur on teams when writing their own style configurations.
I strongly believe that if there were a non-configurable "official" style guide and tool that within a year everyone would just be used to it. There are always people who will fight against a language being opinionated about certain things (look no further than the repeated pitches/proposals to add integer indices for subscripting String). While it would be nice to code however the heck I wanna, I can sacrifice a few of my personal preferences to conform to a uniform style that would make reading any and all swift code just as easy.
Should there be an official style? Yes.
Should there be an official formatting tool that enforces this style? Yes.
I am sick of having to think about (and talk about) tabs, spaces, parentheses, colons, etc. What a colossal waste of time! I want to focus on architectures, modules, interfaces, data, etc. Not some typewriter settings. So I say bring it on!
Ideally, the official formatter would have zero configurability, i.e. this is the one true official style; no more discussions about e.g. how to tweak its million settings, etc.
If, hypothetically, it is decided to have an official non-configurable tool, I think it's a fair bet that there will be at least one configurable unofficial alternative (especially since, as mentioned, there are already a few tools that are pretty far along). It's also a fair bet that such tools would also support the official style, as a built-in configuration option if not the default. I think that would somewhat reduce the popularity, and therefore the usefulness, of the official tool.
One option is that the official tool could be non-configurable in its "1.0" form, and options could be added later on.
Exactly, for the first iteration I would prefer a non-configurable formatting tool. Then, if the community sees the need for it, we could add some level of configuration.
First of all, I don't think that minor differences in style are a bad thing (TM) and especially for very complex codebases, the idea of everyone's code looking the same (down to the choice of using loops vs. map/reduce) seems utopian to me. That said, sometimes I have ended up working with developers that make very poor (as in, probably objectively poor) formatting choices. Sometimes, this is because the developers are still quite junior and haven't yet developed enough aesthetic sensitivity and/or are somewhat overwhelmed having to grapple both learning the language and the style; sometimes, it's because they're technically brilliant but somewhat disorganised minds; etc.
That's why I think that making it easier to integrate some automated style guide check is very useful, especially for somewhat bigger and more diverse teams; otherwise we have to either live with very weird code being checked in or with style arguments in PRs (which I think is the wrong thing to do, in PRs).
Now, there are already tools that help with this, for example SwiftLint (which we already use). But currently, it seems to be somewhat too limited / not comprehensive enough. Also, there's issues with XCode's auto-formatting—one pet peeve of mine is the indentation of else in multi-line guards (which, in our codebase, are extremely frequent).
I'm not really sure we need a new tool. I'm also not sure we need a one-size-fits-all code style (others have mentioned how complex the Swift language is as opposed to e.g. Go, and I also think that due to the kind of problem domain you're working on you might use certain features more than in most codebases, like multi-line guards). What I do think we'd need is a better way to get started with things like SwiftLint (e.g. integration into XCode), making SwiftLint more powerful (so it can also check some formatting choices and auto-correct them, etc.). It's fine, IMHO, to have some "starter" code style that can get people (especially newbies) started very quickly, but I would also argue that it should be made configurable.
