Strong -1. This is a syntactic sugar proposal that does not even attempt to live up to the standards of sugar proposals (enabling new kinds of expressivity to improve clarity), which introduces more ambiguities into the grammar, and could cut off future lines of evolution.
This sort of proposal makes Swift less uniform and pushes it towards the direction of Perl, where early in its life, people spent time trying to "make syntax work" and it turned into a pile of special cases.
This proposal is akin to allowing the colon to be emitted between a variable name and a type (golang style) in certain cases. Yes, it could be done in certain cases, but not all, and the irregularity introduced would harm the language for almost zero benefit.
No. I have never heard anyone complain about this in a serious way.
No, it reduces clarity, and introduced grammar ambiguities that don't otherwise exist. What is the meaning of this code, and why do we want it to be "unclear"?
var x : Any = [
foo
(6 * 9) // Function application or separate value?
]
The "When will you still use commas" section points out several other weird and non-obvious cases that make the language harder to understand.
If this proposal were to be taken seriously, it should also allow omission of the semicolon in single-line statements lists "in the cases when it could work".
I've participated into this in the various incarnations that have spanned various pitch threads. The concerns I raised before have not been addressed.
These are the points of concern I raised on the pitch thread:
- The entire premise of this proposal is that separators do not provide value to humans. This is not obviously true and I would like to see some evidence to defend this position.
- As you point out in your 'exceptions' section, the Swift grammar relies on juxtaposition and sequencing as part of the existing grammar. This is a source breaking change for at least some cases.
- Taking this significantly restricts future evolution of the language, by taking away juxtaposition from the expression grammar. This is extremely problematic for me given the early development of the Swift language. We should not be pouring sugar in as tasty mortar to fill the grammatical cracks in the Swift building - we need to be able to drop entirely new bricks into the language in the future, and that sugar will get in the way, and make evolution much more difficult.
- This is trivial sugar with almost no benefit. The only precedented discussions we have had along these lines have been about allowing an extra comma at the end of an argument list (to allow copy and paste) and those have been extremely controversial to say the least. I don't see why we'd go completely the opposite way and take away all separators.
- I suspect that this will significantly regress QoI on error diagnostics in common cases in the user/IDE experience.
-Chris