or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
More information about the Swift evolution process is available at
Trailing commas is clearly very useful in the collections case. While that
case is more common than functions and tuples, I don't see any reason that
collections should be treated as a special case. Why should some
comma-separated lists allow trailing commas and some not?
This seems a reasonable move towards consistency and is useful in some
cases while not harmful in others. When in doubt, I'd rather broad rules
("trailing commas are allowed in comma-separated lists") rather than
special cases. This improves teachability.
It also improves diffs when functions pick up new parameters, particularly
ones with default values. This is particularly common (and expected) in
constructors. That's valuable.
* Is the problem being addressed significant enough to warrant a
change to Swift?
As a language rule simplification, I believe it's worth a change if it
doesn't introduce problematic corner cases. The fact that it improves diffs
is no less valuable for functions than it is for collections.
* Does this proposal fit well with the feel and direction of Swift?
Yes; it definitely feels Swifty in the same way that it does for
collections. There's no reason for Swift to treat them differently.
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
I've seen this in Perl, Python, and Go. Basically every language I've used
that allows trailing commas in collections also allows them in function
calls. In Go, the trailing comma is mandatory in some cases. This has been
nice for consistency.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Quick reading.
-Rob
···
On Tue, May 10, 2016 at 2:53 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
-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.
···
On Tue, May 10, 2016 at 11:53 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
I would love this, but I’d hate any language which allows it.
Maybe we could degrade it to a warning instead of a compile error? So it’d be fine in scripts and when debugging, but you’ll be reminded that leaving it that way is not cool.
···
On 10 May 2016, at 20:53, Chris Lattner via swift-evolution <swift-evolution@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:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
More information about the Swift evolution process is available at
-1. Even if I see the arguments in favour, I am of the same opinion as Tony Allevato and Chris Latner: tuples and parameter lists are most often fixed size, which reduces the usefulness of this proposal. And if the proposal is accepted, where do we stop? Do we then accept it in generic parameter list? In where constraint lists? If there is a limit not to cross, I think this proposal is it.
* Is the problem being addressed significant enough to warrant a change to Swift?
I don’t think so.
* Does this proposal fit well with the feel and direction of Swift?
I don’t think it either fits or not with the feel and direction.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I think not. If I have used other languages which allow it, I am not aware of it.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I spent a lot of time thinking about it since it was first discussed. My opinion went back and forth but I am now sure of my opinion.
+1 from me. We should be consistent in either accepting or rejecting trailing commas everywhere we have comma-delimited syntax. I'm in favor of accepting it, since it's popular in languages where it's supported to enable a minimal-diff style, so that changes to code don't impact neighboring lines for purely syntactic reasons. If you add an argument to a function, without trailing comma support, a comma has to be added to dirty the previous line:
In languages that don't support trailing commas, many users resort to the abomination of leading-comma style, strangely popular in Haskell and related languages:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
More information about the Swift evolution process is available at
I don’t like the proposal. I understand the flexibility it gives to rearranging elements but to someone reading the code it looks like an element was removed by mistake.
* Is the problem being addressed significant enough to warrant a change to Swift?
I don’t think it needs to change at the expense of making code look like an error was made.
* Does this proposal fit well with the feel and direction of Swift?
No.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I’ve seen this in .plists and other languages. I don’t use it for the reasons mentioned.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick review.
···
On May 10, 2016, at 2:53 PM, Chris Lattner <clattner@apple.com> wrote:
It feels wrong to allow garbage syntax lying around in one's code simply for the sake of occasional convenience. It's like littering on the sidewalk because it's easier than throwing something in a trash can.
Because commas are allowed in several places, and because there is no consistent way to allow a trailing commas throughout the language without allowing at least some scenarios in which a trailing comma would change the meaning of the code, it is not safe for the Swift compiler to assume that a trailing comma is intentional and not a mistake. Doing so would shift a compile-time error to runtime.
* Is the problem being addressed significant enough to warrant a change to Swift?
No. Not terminating a list with a comma is about as much of a "problem" as having to terminate strings with a quote.
* Does this proposal fit well with the feel and direction of Swift?
Making Swift more forgiving of bad syntax does not feel very Swifty to me.
Allowing trailing commas everywhere comma separation is used would be consistent, but would make Swift less strict and less safe. Allowing trailing commas only in those places where they could not possibly affect runtime behavior would be safer, but would make the language less consistent. Either option is sub-optimal.
* 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've never used the feature in any other language, because I don't find trailing commas visually appealing. They make the code look the developer forgot to finish working on it.
-1. I support the opinion that dictionary/array is different "thing" than parameters in functions/methods and parameters in tuples.
* Is the problem being addressed significant enough to warrant a change to Swift?
I don't think so. For me the proposal is not solving a problem in Swift, not improving Swift.
* Does this proposal fit well with the feel and direction of Swift?
I don't think so. For me the proposal adds confusion to Swift, especially for novice coders. Like "why comma placed here.. are we expecting some additional parameters here.. is it the same as variable arguments" etc
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I wanted trailing commas for array/dictionary in other languages, but not for functions/methods/tuples.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
-1 for me. This proposal inspired me to start participating again. :]
The perceived benefits aren’t worth the visual noise to me. (It looks half-baked to my eyes.) I *really* want to avoid having to and a custom linting step in all my projects. I further fear if this did become possible, I would somehow end up on a project where having extra commas *everywhere* was part of some coding standard. Noooooo! :]
* Is the problem being addressed significant enough to warrant a change to Swift?
Not from my vantage point. If anything, I would remove the capability for collections. I was blissfully unaware of the functionality before reading this proposal.
* Does this proposal fit well with the feel and direction of Swift?
I don’t believe so. BTW, what about enum case statements? enum Few { case one, two, three, } Or generic argument lists (I think as someone already mentioned.) Shouldn’t those support extra commas too? (No please! Haha. :)
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Similar to Swift, C++ ignores trailing commas in some situations, but not for param lists. I actually did use this feature in a few instances where the lists where frequently changed as it helped with merges. I put up with it because it was in a few limited contexts and not everywhere. This proposal would make it *everywhere* I fear.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Reading through the proposal and skimming the threads.
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.
* Is the problem being addressed significant enough to warrant a change to Swift?
It's a minor issue, but it's a minor fix too.
* Does this proposal fit well with the feel and direction of Swift?
Yes; this brings function call syntax in line with other comma-separated lists.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I've used a number of languages like this and it does come in handy occasionally.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick reading, plus participation in previous discussion (where I took the other side).
What is your evaluation of the proposal?
+1. Commas are already redundant syntax to provide additional clarity over spaces in nearly all use cases. Being strict on this provides no material benefit. On the other hand, being super strict about this does have measurable, real-world impacts. I can provide examples of days of build time and breaking change back-outs because C++ lacks this very feature.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes.
Does this proposal fit well with the feel and direction of Swift?
Yes
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Yes. It scales well to large team sizes as well, especially within the context of merging code together. The code that used trailing commas never has potentially build breaking merges in this same context. However, when merging C or C++ code, this is often a headache to deal with this.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve read the proposal and used languages both with and without this feature.
-David
···
On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution <swift-evolution@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:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
More information about the Swift evolution process is available at
While I appreciate the ease of reordering and commenting out that the proposal brings, I think it hurts readability. Also, it seems to me that keeping the commas in check is a job of a IDE, not language syntax feature.
The analogy for me is the Lisp parentheses problem. It’s often even more difficult to manage parens while editing and commenting code. Instead of providing a language syntax feature that makes the number of trailing parents flexible, it was better solved with IDE feature called Parinfer.
* Is the problem being addressed significant enough to warrant a change to Swift?
I do not think so. It’s a minor issue with minor consequences.
* Does this proposal fit well with the feel and direction of Swift?
The only part of Swift “feel and direction” that I think can be of relevance is its focus on educational cases. I do not have any data concerning whether trailing commas will be easier or harder to grasp by the students. However, it’s one more think to explain.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I’ve used a little Python and JavaScript. I didn’t use this feature in those languages, but it was just me. I think it fits better with their scripting style, where by “scripting” I mean very forgiving, very flexible (multiple ways to achieve the same effect) and hardly ever preventing you from making mistakes. I think Swift was always trying to drive away from this attitude and replace it with “scripting syntax for safe language” one.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve read the proposal and related discussion.
Trailing commas look like a mistake. While having to clean them up when editing parameter lists is unfortunate I prefer it to the untidy and erroneous look of trailing commas in the code. Remember that code is more often read than written, so the preference should be on readability.
I am not convinced by the diff argument either.
I am reluctantly ok with the existing ability to place trailing commas in arrays or dictionaries because these are conceptually more open than parameter lists or tuples or generic argument lists etc.
I’d prefer the alternative proposal of being able to omit commas when placing expressions on different lines (just like with semicolons), although I haven’t thought about possible parsing problems which might arise because of that.
But as long as I am not required to use trailing commas, I’m not strongly against this. There are more important changes to be made. I just think it is a bad idea :-)
* Is the problem being addressed significant enough to warrant a change to Swift?
No, the task of cleaning up parameter lists is small compared to the untidy and erroneous look of trailing commas. In addition cleaning up is only necessary at the end of lists.
* Does this proposal fit well with the feel and direction of Swift?
No. An important feature of Swift is readability which is disturbed by trailing commas.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I haven’t.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Followed the discussion and weighed the convenience of trailing commas against the impact on readability.
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
More information about the Swift evolution process is available at
- I think it makes the code look ugly and incomplete when there is a trailing comma
- I much prefer the counter-proposal which would allow newline to be the separator for items in a list.
- in general, it’s much better when you can remove something from your code rather than add something to it
- this proposal serves the same purpose as allowing the trailing comma
-Kenny
···
On May 10, 2016, at 11:53 AM, Chris Lattner <clattner@apple.com> 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:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
More information about the Swift evolution process is available at
Parameter lists and tuples are also structurally different than collections. Parameter lists also have labels, and (depending on how the ‘disable reordering default arguments’ decision goes) parameters may not be added and reordered arbitrarily. Tuples are different because adding a member will often break all the code downstream because it changes the type of the value. This is different than array and dictionary literals.
The only “collection like” aspect I can think of is for variadic parameter lists, but I don’t think they’re common enough to provide a special case for.
-Chris
···
On May 10, 2016, at 12:36 PM, Tony Allevato <allevato@google.com> wrote:
On Tue, May 10, 2016 at 11:53 AM Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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:
-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.
Swift serves production code, but it also serves code for teaching, for documentation, for samples, for shell scripting, and for many other purposes. What "smells" in one use may not "smell" in another.
Reordering and commenting in and out parameters is especially handy while prototyping, experimenting, and sometimes even for production code where user feedback may affect tuning choices (working in AVFoundation is a particularly good example of this), especially in a language with default parameters where the final parameter may not always be in use.
As a heavy user of source code that extends beyond simple production goals, I would greatly benefit from their inclusion into the language. I do not believe doing so would adversely affect traditional coding.
It is easy enough to use a linter to remove trailing commas. It is impossible to lint them into the language.
-- E
···
On May 10, 2016, at 1:36 PM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:
On Tue, May 10, 2016 at 11:53 AM Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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:
-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.
-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.
FWIW, I personally agree with this observation.
Parameter lists and tuples are also structurally different than collections. Parameter lists also have labels, and (depending on how the ‘disable reordering default arguments’ decision goes) parameters may not be added and reordered arbitrarily. Tuples are different because adding a member will often break all the code downstream because it changes the type of the value. This is different than array and dictionary literals.
A parameter list or tuple may have a specific arity and order at a point in time, but function signatures still evolve.
The only “collection like” aspect I can think of is for variadic parameter lists, but I don’t think they’re common enough to provide a special case for.
IMO, this is *already* a special case. It feels like an arbitrary inconsistency that some comma-separated lists admit trailing commas and some don't. I don't think users are thinking of a "structural difference" between collections and arguments when working with them, they just see the syntax.
-Joe
···
On May 10, 2016, at 1:58 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 10, 2016, at 12:36 PM, Tony Allevato <allevato@google.com> wrote:
On Tue, May 10, 2016 at 11:53 AM Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
I will like to suggest the alternative
that consists in eliminating the use of "," since the compiler is able to know here they are expected, automatic watermarks can be added by Xcode to indicate where the compiler is automatically adding the comas.
also use of a “..” watermark at the end of a line will indicate that it continues on the next line, it will also be added on the start of the next line as well.
Optionally watermark numbers can be added to indicate the number of elements in a line or the accumulated total
This change will make it easier for user to rearrange list, and eliminate the “Expected ‘,’ separator” error without making the code less safe or less readable. It also doesn’t have any impact on existing code since the user could still use the “,” manually
There could be cases were the user will still need to type “,” if the grammar is ambiguous
The use of the ";" can also be eliminated using similar logic
···
On May 10, 2016, at 2:05 PM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:
On 10 May 2016, at 20:53, Chris Lattner via swift-evolution <swift-evolution@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:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
More information about the Swift evolution process is available at
I would love this, but I’d hate any language which allows it.
Maybe we could degrade it to a warning instead of a compile error? So it’d be fine in scripts and when debugging, but you’ll be reminded that leaving it that way is not cool.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
