Fully support your opinion.
> PS: can they actually be removed EVERYWHERE instead?!
Yes, I believe it will be much better to propose feature to allow line
break instead of comma, so we can have:
let x = [10
20
30]
let y = [1 : "one"
2 : "two"]
(from proposal):
func padStringToLength(
sourceString: String
destinationCount: Int
paddingStyle: StringPaddingStyle = .Left
paddingCharacter: Character = " "
) -> String {
/* ... */
}
padStringToLength(
sourceString: "source"
destinationCount: 4
paddingStyle: .Right
paddingCharacter: ""
)
let tuple: (
string: String
number: Int
) = (
string: "string"
number: 0
)
... <SomeT
SomeU
SomeV> ...
This solves all the problems with diffs, makes code much clean and nice, no
additional noise. Why we need these commas instead of this solution? IMO
this will be real step forward.
Is there such a proposal? (Or probably was discussed already?)
On 12.05.2016 7:46, L Mihalkovic via swift-evolution wrote:
-1 - for ever
On May 11, 2016, at 6:47 PM, Joe Groff via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution
<[email protected] <mailto:[email protected]>> 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:
https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
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
https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,
-Chris Lattner
Review Manager
+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:
--- a.swift
+++ a.swift
foo(
x: 0,
- y: 1
+ y: 1,
+ z: 2
)
Trailing commas avoid this:
--- a.swift
+++ a.swift
foo(
x: 0,
y: 1,
+ z: 2,
)
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:
I am not sure I understand where the “abomination” lies in using
leading-comma style… but I will try to see it.
--- a.swift
+++ a.swift
foo( x: 0
, y: 1
+ , z: 2
)
I think the trailing-comma syntax jives much better with Swift style.
If commas are to be construed as elegantly but meaninglessly dropped little
crumbs, then one can see why it might not matter where they go, or how many
there are, which as well as begging the question of allowing them at the
end, should equally prompt the question of completely removing them
altogether. And if having extras is just /great anticipation on future
needs/, should we think about considering the following lines as all equivalent
let v0 = (1,
2,
3)
let v1 = (1,
2,
3,
)
let v2 = (, // just in case I want to add something at the front later?!
1,
2,
3,)
let v3 = (1,
2,
,
3,
) // just in case I want to add something in the middle or
front later
let v4 = (1,,
2,,
3,,) // lets be really good programmer, in case it doubles in
length
Aside from the good-anticipation interpretation of trailing commas, there
is also the /thinking-interuptus/ line of interpretation:
this and
that and
standing for: now hold your breath, I am not done.. or maybe I lost my
train of thoughts so I am actually done… who knows.. read the next line to
figure that out.
As I recall there is an ongoing debate about long string literal… Perhaps
this line of thinking can help there too?!! Swift would become very unique
and progressive with something like:
let var = this is a long string literal” // notice my continuation quote
at the end
which I am continuing to the” // notice how I am letting people
know that, like my parameter list,
next line and perhaps even” // my string may not be quite
finished yet
to the next one and even” // …
Like in the convenient case of a trailing comma in a parameter list, I
added a last quote character so that I can add another string later,
without having to resort to the /cliche/ notion of a leading quote. and
like with trailing commas, it is just a placeholder because my string is
really finished for now!
Another convenient area where this reasoning could potentially be applied
might be logical expressions!!! The ability to anticipate on future needs
to change a logical expression might also be neat there by allowing
expressions like:
if (cond1 &&
cond2 &&) {
}
which floats a lot than the overly tight:
if (cond1
&& cond2) {
}
I think I’m convinced… it is such a powerful concept it should probably
extend to the english language at large and
Cheers
LM/
[just in case, I hope everyone has seen the tongue-in-cheeks tone ;-) ]
PS: can they actually be removed EVERYWHERE instead?!
-Joe
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
