[swift-evolution] Allowing trailing commas in argument lists
Radosław Pietruszewski
radexpl at gmail.com
Thu Mar 10 10:28:12 CST 2016
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 at 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 at swift.org <mailto:swift-evolution at 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 at gmail.com <mailto:radexpl at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>
>>>>>>
>>>>>> On Mar 9, 2016, at 2:34 PM, Grant Paul <grp at fb.com <mailto:grp at 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: https://gist.github.com/isaacs/357981#gistcomment-397 <https://gist.github.com/isaacs/357981#gistcomment-397> — 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 at gili-labs.com <mailto:gili.patrick.r at 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,
>>>>>>> -Patrick
>>>>>>>
>>>>>>>> On Mar 9, 2016, at 9:44 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160310/80350e32/attachment.html>
More information about the swift-evolution
mailing list