Allowing trailing commas in argument lists


(Ted van Gaalen) #1

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,
   )


Roadmap for and state of single element tuple types?
(Patrick Gili) #2

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@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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Grant Paul) #3

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 — 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.

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> 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@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
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=


(Patrick Gili) #4

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 — 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.

···

On Mar 9, 2016, at 2:34 PM, Grant Paul <grp@fb.com> wrote:

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,
-Patrick

On Mar 9, 2016, at 9:44 AM, Ted F.A. van Gaalen via swift-evolution <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
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=>


(Paul Ossenbruggen) #5

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? :slight_smile:

···

On Mar 9, 2016, at 12:47 PM, Patrick Gili via swift-evolution <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: 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@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,
-Patrick

On 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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Radek Pietruszewski) #6

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> 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? :slight_smile:

On Mar 9, 2016, at 12:47 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 9, 2016, at 2:34 PM, Grant Paul <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: 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@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@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
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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ted van Gaalen) #7

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> 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> 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? :slight_smile:

On Mar 9, 2016, at 12:47 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 9, 2016, at 2:34 PM, Grant Paul <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: 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@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@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
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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Paul Ossenbruggen) #8

Swift already enforces some formatting rules, for example:

x==y or x == y is legal

but

x ==y or x== y is not.

This kind of sloppiness not allowed. You have to pick one, spaces or no spaces not a mixture. I don’t think Swift should be an enabler of sloppiness.

To radek’s comment that linters are there for this, this means that I have to run it, and then we lose the main suggested advantage of the trailing comma which is that we don’t have two diff lines because I would be sure to make the linter remove the extra comma. Having that extra comma just looks wrong, just as it look wrong for me end an English sentence with a comma,

As others have said, it is more likely an indication that it was an incomplete thought or mistake.

···

On Mar 10, 2016, at 4:34 AM, ted van gaalen <tedvgiosdev@gmail.com> 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? :slight_smile:

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: 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@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,
-Patrick

On 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


(Nisse Bergman) #9

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> 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? :slight_smile:

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: 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@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,
-Patrick

On 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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Radek Pietruszewski) #10

Swift already enforces some formatting rules, for example:

x==y or x == y is legal

but

x ==y or x== y is not.

This kind of sloppiness not allowed. You have to pick one, spaces or no spaces not a mixture. I don’t think Swift should be an enabler of sloppiness.

AFAIK, It’s not allowed because it creates a potential parsing ambiguity, not because Swift wants to police your style.

To radek’s comment that linters are there for this, this means that I have to run it, and then we lose the main suggested advantage of the trailing comma which is that we don’t have two diff lines because I would be sure to make the linter remove the extra comma. Having that extra comma just looks wrong, just as it look wrong for me end an English sentence with a comma,

As others have said, it is more likely an indication that it was an incomplete thought or mistake.

Just as skipping “self.” looks wrong and sloppy to some people. But it’s useful enough that it’s better to allow it and let people who dislike it enforce their own rules with a linter.

Again, being able to write:

SomeStruct(
    foo: …,
    bar: …,
    baz: …,
)

is simply useful. You can add remove, add, and reorder parameters without worrying about commas. We have this in the array syntax already, and I seriously doubt anyone has ever been confused by it.

···

On 10 Mar 2016, at 16:59, Paul Ossenbruggen <possen@gmail.com> wrote:

On Mar 10, 2016, at 4:34 AM, ted van gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> 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? :slight_smile:

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: 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@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,
-Patrick

On 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


(Radek Pietruszewski) #11

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> 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? :slight_smile:

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: 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@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,
-Patrick

On 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


(Myles La Verne Schultz) #12

I feel like trailing commas are much more syntax related than formatting related. I think one should be able to format how they like, but when it comes to syntax, there need rules. Otherwise, there is no language.

Personally, I find the trailing commas irritating. Placing a trailing comma because you think you might add some later causes a error in Xcode. It seems like people just want a reason to allow their code to build/run without getting the error. That doesn't have anything to do with making the language better. It has a lot to do with being allowed to be lazy. If you think there is something you might want to add to the stem of your function, // TODO: is a better way to go.

Myles

···

Sent from my iPhone

On Mar 10, 2016, at 10:30 AM, Nisse Bergman via swift-evolution <swift-evolution@swift.org> 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> 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> 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> 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? :slight_smile:

On Mar 9, 2016, at 12:47 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 9, 2016, at 2:34 PM, Grant Paul <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: 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@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@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
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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Nisse Bergman) #13

I’m not upset at all. I just think the benefits does not warrant a change in the language :slight_smile:

Nisse

···

On 10 Mar 2016, at 17:28, Radosław Pietruszewski <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? :slight_smile:

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: 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@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,
-Patrick

On 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


(David James) #14

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> wrote:

I’m not upset at all. I just think the benefits does not warrant a change in the language :slight_smile:

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? :slight_smile:

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: 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@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,
-Patrick

On 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
https://lists.swift.org/mailman/listinfo/swift-evolution

David James


(Erica Sadun) #15

Trailing commas enable easier re-ordering of arguments, simplify growing or compacting argument lists, and do no harm.

Their use in arrays and dictionaries are conventional enough that experienced programmers will not be surprised by their
presence. No one will force their use and one's internal style guide (and linters) can direct whether any individual group
adopts or ignores the addition.

For those of us who prefer trailing commas, it will be both a convenience and an asset. For those against, there's no harm
done. I find it unlikely that trailing commas will naturally lead to any unsafe code or produce a net negative effect on the
language or the code-base it supports.

-- Erica

···

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.


(Jonathan Tang) #16

One concern I have is whether it might paint Swift into a corner later in
terms of the syntax it may adopt for future features. Are we sure we'll
never want an omitted argument to mean something else, eg. "use the
defaults" or "splat the first two elements of the last parameter"? Or that
it'll never create a grammar ambiguity with some construct we *do* want to
support?

I'm largely neutral on the feature itself. Trailing commas have been
somewhat helpful when working with some large-scale codebases - they reduce
edit conflicts when adjacent lines are changed. But I've also seen the
problem where a trailing comma was a function call that I forgot to
finish. And my code is not noticeably worse for their lack - it's just an
extra 5 seconds or so to update the next line.

Probably my vote would be "defer", and let the other changes slated for
Swift 3 & 4 work there way out. Then we could see how the language evolves
in syntax, and how big a problem this is in practice, and then add trailing
commas in a year or two if people still believe it's a good idea.

···

On Thu, Mar 10, 2016 at 12:27 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

On 10 Mar 2016, at 17:28, Radosław Pietruszewski <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.

Trailing commas enable easier re-ordering of arguments, simplify growing
or compacting argument lists, and do no harm.

Their use in arrays and dictionaries are conventional enough that
experienced programmers will not be surprised by their
presence. No one will force their use and one's internal style guide (and
linters) can direct whether any individual group
adopts or ignores the addition.

For those of us who prefer trailing commas, it will be both a convenience
and an asset. For those against, there's no harm
done. I find it unlikely that trailing commas will naturally lead to any
unsafe code or produce a net negative effect on the
language or the code-base it supports.


(Patrick Gili) #17

Hi Erica,

I disagree that trailing commas can lead to unsafe code. What if I'm coding the initialization of an array or dictionary, I'm interrupted, and I forget to go back and finish it. There's a trailing command left dangling in the initialization code. Today, the compiler warns me, I go back and have an "aha moment', fix the code, and everyone is happy. If we allow trailing commands, the compiler never warns me, I'm left with unfinished initialization code, it builds anyways, and I have a bad day.

Cheers,
-Patrick

···

On Mar 10, 2016, at 3:27 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

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.

Trailing commas enable easier re-ordering of arguments, simplify growing or compacting argument lists, and do no harm.

Their use in arrays and dictionaries are conventional enough that experienced programmers will not be surprised by their
presence. No one will force their use and one's internal style guide (and linters) can direct whether any individual group
adopts or ignores the addition.

For those of us who prefer trailing commas, it will be both a convenience and an asset. For those against, there's no harm
done. I find it unlikely that trailing commas will naturally lead to any unsafe code or produce a net negative effect on the
language or the code-base it supports.

-- Erica

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Rainer Brockerhoff) #18

Trailing comma is not nonsensical, there is a specific purpose in allowing it (unlike your examples), and there’s precedent in Swift already.

Trailing commas enable easier re-ordering of arguments, simplify growing or compacting argument lists, and do no harm.

Their use in arrays and dictionaries are conventional enough that experienced programmers will not be surprised by their
presence. No one will force their use and one's internal style guide (and linters) can direct whether any individual group
adopts or ignores the addition.

+1!

I became aware that trailing commas were now allowed in (Obj)C
relatively recently and use them exclusively now in lists of enums,
array and dictionary constants, and so forth.

Of course with a preprocessor they allow conditionally inserting
elements without any conditional gimcrackery or the hack of inserting a
final dummy element without a trailing comma.

Even so, optional trailing commas will no doubt be useful in Swift too.
I think specifically of commenting out (or uncommenting) elements during
debugging or exploratory programming.

For those of us who prefer trailing commas, it will be both a convenience and an asset. For those against, there's no harm
done. I find it unlikely that trailing commas will naturally lead to any unsafe code or produce a net negative effect on the
language or the code-base it supports.

Excellent argument, too.

···

On 3/10/16 17:27, Erica Sadun via swift-evolution wrote:

On 10 Mar 2016, at 17:28, Radosław Pietruszewski <radexpl@gmail.com <mailto:radexpl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/


(Ted van Gaalen) #19

Please don’t allow these trailing dangling commas. !

I’ve lived all my IT-life without this kind of irregularities,
it’s unnecessary and invites errors.
If the wear and tear of your Del and/or Backspace keys
is a problem, I’ll be delighted to send replacement keys
by DHL or so. Please specify the type of keyboard what you are using.
Ted

···

On 10.03.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> wrote:

I’m not upset at all. I just think the benefits does not warrant a change in the language :slight_smile:

Nisse

On 10 Mar 2016, at 17:28, Radosław Pietruszewski <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> 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> 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> 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> 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? :slight_smile:

On Mar 9, 2016, at 12:47 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 9, 2016, at 2:34 PM, Grant Paul <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: 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@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@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
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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

David James


(Goffredo Marocchi) #20

+1 strongly agree with Erica. I do not see huge realistic side effects and helping to improve diff's and thus code reviews is a big and important plus :).

···

Sent from my iPhone

On 10 Mar 2016, at 20:27, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On 10 Mar 2016, at 17:28, Radosław Pietruszewski <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.

Trailing commas enable easier re-ordering of arguments, simplify growing or compacting argument lists, and do no harm.

Their use in arrays and dictionaries are conventional enough that experienced programmers will not be surprised by their
presence. No one will force their use and one's internal style guide (and linters) can direct whether any individual group
adopts or ignores the addition.

For those of us who prefer trailing commas, it will be both a convenience and an asset. For those against, there's no harm
done. I find it unlikely that trailing commas will naturally lead to any unsafe code or produce a net negative effect on the
language or the code-base it supports.

-- Erica

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution