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.