[swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

Tony Allevato allevato at google.com
Tue May 10 14:36:32 CDT 2016

On Tue, May 10, 2016 at 11:53 AM Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> Hello Swift community,
> The review of "SE-0084: Allow trailing commas in parameter lists and
> tuples" begins now and runs through May 16. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
>         * What is your evaluation of the proposal?

-1. It makes more sense to allow this for arrays and dictionaries because
are variable-length collections whose literals are much more likely to grow
as a code base evolves (anecdotal personal experience). Tuples are fixed
arity, so proactively protecting oneself with a trailing comma seems like
it would have minimal benefit when the surrounding code would have to
change in other ways.

Likewise for function calls; I would argue that if a function
call/definition's parameter list is likely to grow so much and/or so
frequently that a trailing comma provides significant savings, that's a
code smell that should encourage the author to redesign the function.

Essentially, my argument draws a line between "content" changes where we
should allow this (i.e., you can add an element to an array or dictionary
and the code that uses it works as expected, just iterates over the
additional elements) vs. "structural" changes where we should not (adding
an element to a tuple or a function call is likely to involve changes to
surrounding code as well, so the savings are minimal).

>         * Is the problem being addressed significant enough to warrant a
> change to Swift?

I don't believe so. This feels like a language change that would only
produce cleaner diffs in isolated places in source control. The cases where
one would proactively want to protect themselves against future changes
using this syntax don't seem to warrant a grammar change.

>         * Does this proposal fit well with the feel and direction of Swift?

        * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?

        * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?

I read the proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/39a8332d/attachment.html>

More information about the swift-evolution mailing list