I ask this question because I am following the proposal allow trailing commas currently in review.
Why did Swift adopt the use of commas in the first place?
How hard would it be to parse Swift programs if we didn't have commas?
With commas:
// Declare function
func foo (arg: Int, arg2: Int)
// Invoke it
foo (arg1: 2, arg2: 2)
// Tuple
var u = (1, 2, 3)
// Array
var v = [1, 2, 3]
// Declare generic functiom
func foo <U, V> (u:U, v: V) -> (U, V)
Without commas:
// Declare function
func foo (arg: Int arg2: Int)
// Invoke it
foo (arg:1 arg: 2)
// Tuple
var u = (1 2 3)
// Array
var v = [1 2 3]
// Declare generic function
func foo <U V> (u: U v: V) -> (U V)
Forth doesn't use commas as a separator, but it does use comma to compile data into global memory. Other concatenative languages, like Factor, also don't need commas.
Me too, but I strongly suspect it's just because commas are what I'm used to. Most Lisp languages don't use commas [like this], and I've used Scheme a little myself and don't recall any issues with the "lack" of commas.
There are certainly cases - like with semicolons - where the meaning is ambiguous without an explicit separator. See previous proposals and discussions on eliding commas. As a quick example;
foo(
bar
.baz
)
Does that mean:
foo(bar.baz)
…or:
foo(bar, .baz)
It's certainly solvable (e.g. have an arbitrary rule as to which it means, or require a comma in ambiguous cases like that), but it does show you can't avoid commas entirely.
As to why Swift uses commas, I know this question has been asked before and I've never seen any kind of authoritative answer. I suspect that's the answer in itself - probably the earliest Swift contributors just never questioned the use of commas (coming, as they were, from C/C++/Objective-C where commas are all present and used the same) or didn't feel it was an interesting question to consider [relative to the many other important decisions that had to be made early on].
Think of it in the same way as checksums and error correcting codes. The redundancy is kind of the whole point. Even if a valid program could be unambiguously parsed without commas, their presence makes it easier to infer meaning from partially-invalid syntax, or even for the human to skim the code more quickly, which can also result in “data loss” between your eyes and brain, which the redundancy allows you to reconstruct more easily in your head.
I'm probably the most anti-punctuation person I know working on Swift. I mourn the rejection of SE-0257. But there's no way I'd drop the commas between function parameters on the same line.
(the parentheses around function arguments.... now that's another matter. but probably that would need too many other changes to the language, like a different spelling of unapplied functions... \foo would be far better for that than the absence of parens... but I don't actually think that could fly at this point in the language's evolution and the complexity to the grammar it would require)
Swift could have been designed around not having commas, but that would have resulted in substantially different syntax. And at this point, it's not feasible without effectively becoming a different language. What I think most supporters of forms of the 'no commas' idea don't realise is that there's a fair amount of people who have thought about the issue, and aren't keen on punctuation or boilerplate, and still prefer to have commas, at least in Swift. It's not a matter of inertia or not knowing better.
It seems like the underlying issue that makes it impossible to elide commas is Swift’s support for prefix, suffix, and infix operators that share the same symbol. Without that, the ambiguity is removed and whitespace is sufficient to separate any two expressions. But operators and “operators” like . and - are too deeply ingrained in the Swift experience to remove now.
most people write in those languages and it will be easier to adopt.
