The wave of support, kind words, and tweets after the rejection of SE-0084, which introduced support for trailing commas in declarations and at call sites, has been very kind but rather misses the point of open sourcing the Swift language.
While Apple’s Joe Groff provided a strong voice of support for SE-0084, there were few concurring list members willing to speak up for it.
John Siracusa wrote, “Having used, more or less continuously for my 20 years as a professional programmer, both a language that allows trailing commas and one that does not, I come down pretty strongly on the side of allowing trailing commas (for all the reasons already stated in this thread). If it means requiring a newline after the last comma to make some people feel better about it, so be it.”
Brent Royal-Gordon also voted in favor, “I was skeptical of this until a week or two ago, when I had some code where I ended up commenting out certain parameters. Removing the now-trailing commas was an inconvenience. So, +1 from me.”
The remaining community votes were almost entirely negative, with a special award for honesty for Chris Lattner, “I personally find that style repulsive.” In this light, comparisons to Perl and C that show up after the review period has ended don’t add support or change the outcome.
Unless you’re willing to participate in the Swift Evolution process and speak up for or against proposals, the outcomes may not reflect your specific development needs. The best arguments for or against a proposal are real world code, measurements of use in public and private libraries, and pragmatic use-cases that express why a proposal should be adopted or not. Swift language changes should fix real problems and must be demonstrated with real data.
The best evolution reviews include thoughtful analysis of how a change affects existing code bases, improves outcomes, and compares to other programming languages. They should analyze how the proposal fits with the specific feel and direction of the Swift language. A surprising quantity of review feedback ends up as “+1” or “-1” one-liners, which don’t really help guide the evaluation of a proposal’s merits.
Evolution members are welcome to post their reviews publicly or to directly contact the review manager with private feedback. I have participated privately in a handful of reviews and publicly in others. I’ve abstained from reviewing many proposals (there are now over a hundred of them) when I had no strong feelings or no background to evaluate a topic.
Swift Evolution, as all open source projects, offers an imperfect process:
- There is far too much on-list traffic to keep up with. It helps if you’re specifically dedicated to documenting the language and its process, which is an extreme outlier case.
- Participants are self-selected and skew towards people who dedicate time to debating language design; that time must naturally trade off from work, spending time with family, watching TV, or engaging in other lifestyle activities and hobbies.
- On-list consensus may not match the consensus in the wider developer community and there’s often quite a strong backlash against attempting to measure the temperature of that wider community.
- If you think “best editor” wars are bad, you haven’t seen the bikeshedding over multi-line string grammar.
To be clear, Swift Evolution is not “design by committee” as some mass wave of crowd consensus. The Swift process was designed from the start to be both opinionated (“Swift is an opinionated language”) and focused given the circumstances or community involvement. At this point, I can’t remember if Apple wrote this or I did, but “maintaining that coherent vision for something as complicated as a programming language requires both coordination and leadership.”
The ultimate responsibility for adopting changes lies with the Swift core team, which acts as Swift’s internal star chamber. The team establishes the strategic direction of Swift. Core team members initiate, participate in, and manage the public review of proposals and have the authority to accept or reject changes to Swift.
The majority of work and discussion take place on the highly-trafficked Swift Evolution mailing list. This list provides the platform to propose, discuss, and review ideas to improve the Swift language and standard library. There are few participation rules, mostly to do with adhering to a respectful code of conduct.
Using a mailing list establishes a public record of all proposed changes and their ensuing discussions. Participants can explore archives to determine whether a topic has already been discussed and/or voted on, and what the arguments for and against those changes were. The Swift Evolution archives are available at lists.swift.org and news.gmane.org.
Having votes go against your preferences is part of the reality, and there are often some very good underlying reasons why some proposals go the way they do that are obvious on the larger scale than the smaller (to simplify the language, to enhance reliability, to obtain more accuracy, precision, and speed, because of the internal compiler limitations, etc.) The core team feedback at the end of the review period explains why each vote went the way it did.
That said, each proposal needs its champions. The process can be tedious and needs to be driven from a pitch through drafts, from pull request through review. Supporters should be available through the review process to answer questions, update text, offer code.
With Apple standing behind Swift, its impact is both large and loud. If you love coding and language design, there’s rarely an opportunity like this to become part of the process and help influence its outcome.
5 Comments
All good points. The rejection of SE-0084 may be the the kick in the pants I need to get involved. But it can be hard to find time.
I am quite curious how many of the participants in Swift Evolution are doing it in their 100% free time, and how many of them have jobs in which participating in things like Swift Evolution counts as part of their general work, either as part of skills development or as part of maintaining a public profile for teaching, recruiting, etc..
If your work is very narrowly tied to delivered code, then you can only join in on your own time. And then you need to have your own time! The same issue comes up, of course, for things like preparing and giving talks.
I have a day job which doesn’t include “contributing to the Swift community” as part of its description and there are periods when I can’t get to Swift-evolution for several days.
I currently have 477 unread emails in my Swift-evolution inbox going back to 25th May. You can reckon on 100 messages being added every day which means I think you need an hour a day at least to keep up or two hours if you are actually contributing.
Personally SE-0084 didn’t matter either way to me. If I were actively posting on swift-evolution (I’m not, yet, but I’ve been reading it regularly for a few months now) I’d probably have been a +0.1 vote. It doesn’t seem like accepting the proposal would have created any big problems, but it also doesn’t seem particularly useful, aside possibly from the use case of adding/removing/reordering default parameters at the call site of a function. And with SE-0060 (Enforcing order of defaulted parameters) accepted for Swift 3, that use case is somewhat diminished as well.
Tuples and function calls aren’t the same thing as arrays and dictionaries. If they were to remove trailing comma support in array/dictionary literals, i’d be quite upset! It’s normal to be adding/removing entries to those quite frequently, or to generate those literals with a script. But it’s not at all useful with tuples, which can’t have elements added/removed without changing the type (causing lots of ripple effects elsewhere) and it would have very limited utility when it comes to function paramter lists.
Just replying in terms of call sites, there are not just defaulted parameters but also variadic arguments, as in print statements among others
I think a problem with swift-evolution is that many of the proposers do not honestly evaluate the criterion “the change must solve a real problem”. Too many proposals are of the form “I like the way language x has feature y and this should therefore be in Swift” where the “real” problem is that the person in question wants Swift to be the same as their favourite language.
Another problem is that, quite often, the real problem is pretty minor. The comma proposal falls in to this area IMO. What is the use-case for it? If you have a long parameter list and you have formatted it with one item per line and you want to remove the last argument or you want to add an argument to the end of the list, the comma proposal would save you from editing two lines instead of one. Sorry, but that’s not compelling to me.