I didn’t even know arrays supported trailing commas until I read this thread, so it seems allowing it everywhere will give an additional flexibility to a subset of developers but not “pollute” things for the rest of us (if I can be so bold as to assume the majority prefer the cleaner approach.)
Yeah, I only discovered it by accident maybe two months ago — for >1.5 years of using Swit, I didn’t know it was allowed. Many people have said that — which, I think, is good evidence that, even if not widely used, there’s no harm in allowing it.
Although I’d be saddened by the removal of trailing commas in arrays, I agree it should be consistent.
— Radek
···
On 10 Mar 2016, at 20:37, David James <davidbjames1@gmail.com> wrote:
Seems we should either add trailing commas for ALL arbitrarily ordered lists of things *OR* remove any allowed trailing commas that exist at present (like arrays). To be consistent.
I didn’t even know arrays supported trailing commas until I read this thread, so it seems allowing it everywhere will give an additional flexibility to a subset of developers but not “pollute” things for the rest of us (if I can be so bold as to assume the majority prefer the cleaner approach.)
David
On Mar 10, 2016, at 4:35 PM, Nisse Bergman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’m not upset at all. I just think the benefits does not warrant a change in the language :)
Nisse
On 10 Mar 2016, at 17:28, Radosław Pietruszewski <radexpl@gmail.com <mailto:radexpl@gmail.com>> wrote:
Trailing comma is not nonsensical, there is a specific purpose in allowing it (unlike your examples), and there’s precedent in Swift already.
Why does this proposal make you so upset?
— Radek
On 10 Mar 2016, at 16:30, Nisse Bergman <nisse@potmo.com <mailto:nisse@potmo.com>> wrote:
Should it also be ok to write other nonsensical characters in the code?
I know this is a bit silly examples but should this be OK?
if a>b hello#€€ {c = b}else ((wow)) {c=a;swap(a,b);arrgh(arrghument) asd asd asd asd}}}}}}
Should we allow extra curly braces where the compiler can remove unnecessary characters?
struct Cool {{{{{
}}}}}}}}I don’t see any reason to allow two syntaxes just because you get two lines changed in a diff when you just added one.
Of course you should be able to format your code however you want. Space indent or tabs? I don’t care but this is not formatting, this is syntax.
I actually think that it is good for the community that the formatting stay kind of the same.If you want trailing commas then remove the syntax for non-trailing commas.
Nisse
On 10 Mar 2016, at 13:34, ted van gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Oh no, hurry!! switch of your screens!!
Hide under your desks!!
The SourcePolice-- has arrived!!! :o)Imho people should be free to format and style their source in any way
they like -apart from company and team enforced standards when
working for or with them, of course.
For example, You might have noticed on this forum, e.g. that I always
put brackets on a new line, because I find it much easier to read.(not doing so, I personally consider this as a traditional bad habit,
taken over from C and C++, being useful only in long gone days of limited
screen estate, when printing out sources was often the only way to have a
good impression. Or in digital medieval times, It saved a lot of weight (literaly)
when I still had to edit with punched cards as source carrier, as each card
could only contain 1 line.)Xcode respects largely personal preferences and e.g. in Eclipse, Netbeans
one can set one's own formatting preferences. However, for instance, the
Dart-language-people, in al their unlimited wisdom, found it necessary to
enforce a formatting dictatorship. You can't customize source formatting.
What they enforce is in their vision the only perfect way. Silly.So, it you want to write code like ( fasten seatbelts, please)
if a>b {c = b}else{c=a;swap(a,b);arrgh(arrghument)} // etc.
That's ok with me.. as long as I don't have to maintain your code.
The only (formatting and other) standards one should, or rather, must
conform to are those necessary when working in a team, or e.g.
when contributing source entities to Swift open source.And where is the end? you could even take this 1984 style dictatorship
much further, e.g. by not allowing identifier names to be < 3 characters etc.
(or removing certain unstylish source elements, but that's another matter, is it not?)I'd say, it is rather a matter of commonSense++.
I've worked long ago in a Cobol team where it was not allowed to
start an if block with a "not" like so (in Swift):
if ( ! someFunc(value)
{
spanishInquisition()
}
we then had to write it like so:
if someFunc(value)
{
}
else
{
spanishInquisition()
}
Because that was the company's way of doing things,
stemming from the endless wisdom of the local gods,?
(sorry CommaConfusion (wow, that's a really cool name for a band!))people that worked there for twenty years or so,
without noticing that there is a world outside their fences...but perhaps it also has to do with the fact that,
at least for building my own apps++, I've metamorphosed
into being an Indie Developer, and some aspects of
that are very cool, like not loosing 50% of my time
(although having plenty of it) for team coordination.
The luxury of doing things, at least in this domain,
the way I prefer.TedvG.
On 10 Mar 2016, at 09:09, Radek Pietruszewski <radexpl@gmail.com <mailto:radexpl@gmail.com>> wrote:
This is a linter's job.
Sent from my iPad
On 10 Mar 2016, at 05:28, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Most people are good about it but there is always one or two who take advantage of something like this, and if you allow it they will. I think it would drive me crazy to see this:
let person = Person( id: json['id’], name: json['name’], picture: Im2age(picture), friends: friends,)
This would drive the anally retentive people crazy! I mean Swift was great that it got rid of the braces here:
if x == y {
} else {
}so no more running the parenthesis right up against the if. But someone I know does this now:
if x == y{
}else{
}Arrrgh!
Can we force the space before and after the paren? Without requiring uncrustify? :-)
On Mar 9, 2016, at 12:47 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Mar 9, 2016, at 2:34 PM, Grant Paul <grp@fb.com <mailto:grp@fb.com>> wrote:
Thanks for the feedback everyone! A few more notes to add to the proposal:
- Rust also supports trailing commas in argument lists and tuples.
- Alternative proposals suggested by Haravikk:
1. Support trailing commas only in multi-line argument and tuple declarations. This is an interesting approach, and would codify good practice in the language. It might make the most sense for a lint-style tool. On the other hand, in Swift, the choice of whitespace character is usually not significant. Putting this rule in the language would change that for only a small benefit.
2. Allowing trailing commas except when it could cause ambiguity; for example, with type inference, overloading, or default parameters. This seems like the most complete way to prevent mistakes, but it also seems like it might be difficult to implement if the allowed syntax changed based on the type checker. Would have to defer to people with more experience in the Swift compiler if this is feasible.Nisse —
Echoing what Radek said, the JavaScript “comma first” style comes directly from a *lack* of support for trailing commas (in Internet Explorer specifically). That style appears to have been first suggested here: A better coding convention for lists and object literals in JavaScript · GitHub — part of the rationale was "a final trailing comma will cause errors in MSIE”.
Patrick and Ted —
Do you also see the same issue with incomplete thoughts when writing arrays or dictionaries, where Swift does currently support trailing commas? I think that case would be more likely than in argument lists: an incomplete argument list would fail to compile in most cases from an incorrect number of parameters, but an incomplete dictionary or array would necessarily still compile.
Absolutely.
I work on a geographically diverse team, which demands an interrupt-driven environment. Dealing with phone calls, emails, and IMs must take priority to maintain communication between team members. Sometimes those interrupts deal with code. Thus, if I'm coding a call site or an array/dictionary initialization site when an interrupt comes in, it is likely that I don't switch back to the context, leaving some incomplete code. I'm sure if I put my head to it, I could think of other places allowing trailing commands are going to hurt me more than help me.
It could be a reasonable proposal to disallow trailing commas in all places, albeit one I would disagree with.
Grant
On Mar 9, 2016, at 10:55, Patrick Gili <gili.patrick.r@gili-labs.com <mailto:gili.patrick.r@gili-labs.com>> wrote:
I have to agree with Ted. When I leave a "trailing comma", it's almost always because I constructing a call and didn't finish, for whatever reason. Thankfully, the compiler is nice enough to tell me when I committed this error.
Cheers,
-PatrickOn Mar 9, 2016, at 9:44 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi Paul
I don’t think that is a good idea because:
as in most human languages writing,
the comma tells us,
that more is following,
?
?
.. oops. hey, no more text?So, to me your examples are incomplete statements,
leading to mistakes when editing, me assuming that I
didn’t finish typing the statement, when I started
editing the source say, three months later.
or, doing maintenance and having to fast-read through
many old source files.Is it really so hard to press the DEL key to remove
the trailing comma?Greetings,
TedvG ,(sorry no more text here :0)
Right now, Swift argument lists are not permitted to contain trailing commas. To make multi-line calls easier, we propose allowing trailing commas in argument (and tuple) syntax:
let person = Person(
id: json['id'],
name: json['name'],
picture: Im2age(picture),
friends: friends,
)_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=TiMad4REPS_rpOXRZiQytQ&m=5hE4Yb04I38N2u3hF1YNWi2rnd6td7WW3_sIMgH1UHU&s=QncXBAO3MI-M5GEJ-wFM9qPqCReaGIzogre9d5EubAE&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=TiMad4REPS_rpOXRZiQytQ&m=5hE4Yb04I38N2u3hF1YNWi2rnd6td7WW3_sIMgH1UHU&s=QncXBAO3MI-M5GEJ-wFM9qPqCReaGIzogre9d5EubAE&e=>_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolutionDavid James