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

[Tony Allevato]

On Wed, May 11, 2016 at 8:09 AM Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

>
> To summarize the complaints to date:
>
> * It make code read like errors
> * Arrays and dictionaries are different "things" than parameters and
> tuples; They are structurally different
> * Parameter lists should always be of fixed size at deployment time; Once
> a signature is fixed and consumed, it's difficult to change
>
> To which I reply:
>
> * Well structured code needn't read like an error. The examples above show
> an in-house style that allows final commas. Your in-house style may differ
> and a linter can catch these issues.
> * Both collections and signatures are syntactically similar in layout even
> if they are semantically different in use. In Swift, complex method
> signatures with defaulted arguments like the example shown are not
> uncommon. Do not limit your thinking to single line lists of (x: T, y: U,
> z: V) signatures.
> * Parameter lists and function signatures, like collections, can evolve,
> especially when using defaulted parameters, even when they are consumed at
> multiple points.
>

To me, this reads like a solution in search of a problem, and the arbitrary
syntactical freedom—and IMO, ugliness—that would be allowed by it outweighs
the benefit of not having to type a comma occasionally. We shouldn't just
loosen the syntax of a language arbitrarily because tools can produce
linter warnings or auto-correct them; if we use that as our determining
factor, where do we draw the line?

Once a function signature evolves, you typically have to change all of the
call sites (excepting arguments with default values), which will be a
bigger task than inserting a comma anyway. And if you only have to change
the function definition (if it's a default argument), is the extra comma
you have to add that big of a problem? How often in the process of writing
code is someone going to re-order default arguments that this would be a
significant benefit?

Since you alluded to teaching earlier as a scenario to consider, in my
(anecdotal, of course) experience teaching CS, I've never run into a time
where a student was confused by the inability to put a trailing comma in an
argument list or where it was more than a trivial inconvenience to have to
add one later, but I *can* recall times where they stumbled over trailing
commas when they were present ("does it have a different meaning?" "is
there an empty item in this list?", etc.). That harkens back to concerns
that trailing commas make code look like there's something "missing" or
"left out."

Of course, the argument could be made that I personally would be mostly
unaffected by this change—I don't use trailing commas now and this proposal
wouldn't force me to start. So why do I care? I feel that changes that
would loosen the language syntax should have to meet an extremely high bar
other than allowing for personal style preference or convenience.
Consistency is a good goal, but if that was the argument being made, I'd
argue the opposite direction—commas should be uniformly treated as
separators, not terminators, and should not be allowed in a terminating
position in collection literals either, even despite the fact that I think
there is more of a case to be made to allow them there vs. here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/bd0d0430/attachment.html>