Is the problem being addressed significant enough to warrant a change to Swift?
No. It's syntactic sugar that sacrifices clarity everywhere, for brevity in a few specific circumstances. I would much rather see allowing trailing commas in an expression list as a solution to half the problem this solves. (Or regardless for the sake of consistency).
Commas are IMO the simplest and clearest form of syntax we have, and adding an additional whitespace-as-delimiter case is something that should be considered very carefully, not just thrown in because some people think commas look ugly.
The only compelling case really seems to be EDSLs, but if that is a capability important to Swift, it should be considered more broadly and directly.
If/when this capability is added, I think it should be constrained and explicitly opt-in. Not ever as a general language feature.
Does this proposal fit well with the feel and direction of Swift?
No. It feels like a distraction from adding much needed features and would very likely be problematic to to the already poor (but improving) text editor and IDE support/bugs by adding a complex and unintuitive feature.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Anytime I seen lists without commas it adds a cognitive load to understanding the code I'm reading.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
-1. Iām not in favour. I think the potential for this feature to introduce unexpected errors by novice (and experienced) Swift users to be quite high.
Is the problem being addressed significant enough to warrant a change to Swift?
I do not think so.
Does this proposal fit well with the feel and direction of Swift?
Possibly.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I have not (that I am aware of).
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
It is surprising to me that the proposal makes no effort whatsoever to address a fundamental, credible concern.
I think nothing more than that needs to be said. Frankly, I don't even see how this proposal got this far, given how little thought on Swift's long term goals (clarity, stability, performance, safety) seem to be considered by the author and proponents.
I do not see any benefits, only confusion will arise. If this is allowed, sometimes people will put a comma and sometimes not. I also think that line wrapping of long lines in code editors makes it hard to see if there is a real separator, or not. In contrast, the comma is very clear and works fine as a separator.
At first, I wasn't convinced. It's a subtle change and one I thought was friviless. However, after looking at @nate_chandler and @anandabits examples and exactly how the changes looked; it starts to make sense. The , becomes noise once you see a world without them.
What really brought it home for me though, was the comparison to the ; - We absolutely should do this, to remain consistent.
-1. As many others have also stated, I have never encountered a case where I needed to add a semicolon, but there will definitely be cases where I have to add a comma.
I do not buy the EDSL argument, quote:
The situation with definition of the table in the EDSL is the same. The commas are providing information to nothing and nobody. They are ceremony for its own sake. Moreover, they are a constant visual reminder that you are looking at a list of arguments being passed to a function rather than a list of declarations in the EDSL.
If something is a Swift function call and is executed like a Swift function call, then I want it to look like a Swift function call. A EDSL should not try to rely on obscure syntax features (and IMHO not use weird custom operators either), but instead provide domain-specific types and functions that allow programmers to work at a higher level of abstraction in that domain.
I mostly followed the pitch thread and read the majority of the review thread.
I agree with all of the concerns raised by @Chris_Lattner3. I have also never thought, "Hey, this code needs less commas" and the fact that it would still be required in certain cases is a big downside. Consistency is extremely valuable in my opinion.
Thank you to everyone who has participated in the review of this proposal. I am thrilled to see the amount of passion and energy everyone has in making Swift a better language.
This has been a polarizing discussion. It also has not the best conducted discussions we've had in Swift Evolution's history. In hindsight, this review was launched prematurely while important details were still being shaken out in the pitch phase. It was my mistake, as the review manager, to schedule the review before more of that discussion had settled and the concerns in the pitch phase sufficiently addressed. This is a serious change to the language, and it should not feel rushed or insufficiently vetted. As such, I think it is important to allow the proponents of the proposal to have the opportunity to go back and incorporate the feedback from this review and re-engage the discussion, starting at the pitch phase, before we consider re-engaging this topic for formal review. This is not just my desire as the review manager, but the proposal authors have shared the same opinion and desire.
I would like to take this opportunity to reiterate the importance of the Code of Conduct standards for Swift, and the general principles they are meant to impart on how we run the community. I think it is crucial that reviews should be held to high standards, but we should always refrain from criticizing the review authors or otherwise engaging in what can be perceived as personal slights. Everyone engaged on Swift Evolution is interested in making Swift better, and it takes a lot of guts to write a proposal in the first place and debate it with the community. It is fine to remark that a proposal feels premature to review and that important things need to be considered ā but let's avoid taking it beyond that and making comments about people themselves. Everyone has good intentions here, and everyone should be given the benefit of the doubt even when making mistakes. I hope everyone who participated on this review thread and on the pitch can step back and ask how they would have preferred the discussion on the thread could have gone a bit better, either in their own participation or the participation of others. In every review discussion, let's make sure we learn as a community from that experience so we can continue to find the best way to engage in topics like these that are contentious but are all in the spirit of making Swift better.
I want to extend my sincere thanks to the proposal authors, @nate_chandler and @anandabits, and to everyone who participated in this review.