[Review] SE-0084: Allow trailing commas in parameter lists and tuples

Evolution Announcements
61

Tino, would you like to form an 'official' proposal for this(newlines as separators) feature? As I can see, there is a much support in community for this idea, but no one said yet he/she will create a proposal for this.(or I just missed this)

I feel honored, but I guess there are others (native speaker, closer relation to the core team...) who are better suited than me...
On the other hand, I lack fear of seeing a proposal rejected ;-), so as long as deeper thinking doesn't reveal any downsides, I don't mind spending some hours and putting my name on the pull request.
Afaics, there are no plans to change SE-0084 to at least add "making commas optional if followed by a newline" as an alternative, so the first step would be a separate thread ("Newlines as item separators in lists"?) — but as all examples in the proposal use commas followed by newlines, I think all of its goals could be archived

62

I do it quite a lot, especially for initialising structs, enums. I use it to get the same benefits as a switch statement spread over several lines.

I think it’s often good to liberally apply new lines, as it aids legibility.

Here some sample code of mine using it:

extension ImageGraphic : JSONObjectRepresentable {
   public init(source: JSONObjectDecoder) throws {
       try self.init(
           imageSource: source.decode("imageSource"),
           width: source.decodeOptional("width"),
           height: source.decodeOptional("height")
       )
   }

+1 to the initialization use case. You can do type-safe embedded data this way. Similar to embedding JSON directly, but with type checking and no need for parsing. In that use case the initializer calls may be intermingled with arrays and may have defaulted parameters.

If that use case matters at all allowing trailing commas in the arrays but not the initializer calls would *feel* inconsistent regardless of the technical distinction.

···

Sent from my iPad

On May 13, 2016, at 1:07 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org> wrote:

   public func toJSON() -> JSON {
       return .ObjectValue([
           "imageSource": imageSource.toJSON(),
           "width": width.toJSON(),
           "height": height.toJSON()
       ])
   }
}

On 13 May 2016, at 3:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

   --- a.swift
   +++ a.swift
    foo(
      x: 0,
   - y: 1
   + y: 1,
   + z: 2
    )

Trailing commas avoid this:

   --- a.swift
   +++ a.swift
    foo(
      x: 0,
      y: 1,
   + z: 2,
    )

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

The standard library already uses this style for function parameters, modulo the trailing comma, and I certainly prefer it to:
   

   --- a.swift
   +++ a.swift
    foo( x: 0
       , y: 1
   + , z: 2
       )

I agree that this is even worse, but I also haven’t seen this used in Swift code. Have you? Swift’s strictness with argument labels makes any of this pretty unappealing to use.

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

-Chris
_______________________________________________
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

63

I am, +1 on allowing new lines instead of commas. I suggest you pursue a proposal on that.

I am also +1 on the current proposal because it exists and will be pretty useful in some cases and I can't predict how long it might be until such a new line proposal would be approved. I also think that the choice between them should be a style choice, not one made by the language (as with semicolon) and if anyone chooses commas they should have the utility of the current proposal available to them.

···

Sent from my iPad

On May 13, 2016, at 1:24 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

IMO If we were *really* concerned about this, we should just allow line-break as separator in comma-separated lists.

On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote:
If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

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

64

   --- a.swift
   +++ a.swift
    foo(
      x: 0,
   - y: 1
   + y: 1,
   + z: 2
    )

Trailing commas avoid this:

   --- a.swift
   +++ a.swift
    foo(
      x: 0,
      y: 1,
   + z: 2,
    )

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

Don't be too harsh :-) This style can be used with much profit when there are several closure arguments:

   foo(
       x: {
           // several lines of code
       },
       y: {
           // several lines of code
       }
   )

Sorry, but this kind of code writing evokes to me the kind of stream-of-consciousness-scripting I was happy to leave behind when I quit perl (or the one *modern* Javascript is ridden with). But I get it, it is an age old psych principle that it is easier for us to ask to be enabled than it is to self-discipline ourselves. I think it is an addiction lambdas have enabled... why would I have to think about the large scale structure of what I do when I can shove a bunch instructions as a parameter. don't get me wrong, i use lambdas a lot in java, but I use method references as soon as it starts to look smell like I am about to stuff all the logic as parameters.

Regards
LM
(From mobile)

···

On May 13, 2016, at 7:58 AM, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

Le 13 mai 2016 à 07:01, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :
On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

For example: https://github.com/groue/GRDBDemo/blob/cd8b9d5cadc3c6c66fd0da4869d820c6624fdf79/GRDBDemo/PersonsViewController.swift#L12-L44

Gwendal Roué

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

65

It seems like all problems could be solved by allowing line-break instead of comma in list:

  public init(source: JSONObjectDecoder) throws {
    try self.init(
      imageSource: source.decode("imageSource")
      width: source.decodeOptional("width")
      height: source.decodeOptional("height")
    )
  }
  
  public func toJSON() -> JSON {
    return .ObjectValue([
      "imageSource": imageSource.toJSON()
      "width": width.toJSON()
      "height": height.toJSON()
    ])
  }

Shouldn't we move in that direction? Probably in addition to allow trailing comma just to allow one to use his/her preferable formatting

···

On 13.05.2016 9:07, Patrick Smith via swift-evolution wrote:

I do it quite a lot, especially for initialising structs, enums. I use it to get the same benefits as a switch statement spread over several lines.

I think it’s often good to liberally apply new lines, as it aids legibility.

Here some sample code of mine using it:

extension ImageGraphic : JSONObjectRepresentable {
  public init(source: JSONObjectDecoder) throws {
    try self.init(
      imageSource: source.decode("imageSource"),
      width: source.decodeOptional("width"),
      height: source.decodeOptional("height")
    )
  }
  
  public func toJSON() -> JSON {
    return .ObjectValue([
      "imageSource": imageSource.toJSON(),
      "width": width.toJSON(),
      "height": height.toJSON()
    ])
  }
}

On 13 May 2016, at 3:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
  - y: 1
  + y: 1,
  + z: 2
   )

Trailing commas avoid this:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
     y: 1,
  + z: 2,
   )

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

The standard library already uses this style for function parameters, modulo the trailing comma, and I certainly prefer it to:
  

  --- a.swift
  +++ a.swift
   foo( x: 0
      , y: 1
  + , z: 2
      )

I agree that this is even worse, but I also haven’t seen this used in Swift code. Have you? Swift’s strictness with argument labels makes any of this pretty unappealing to use.

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

-Chris
_______________________________________________
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

66

I don't see why we need to micromanage the situations where trailing commas are allowed. That's just unnecessarily increasing the fractal complexity of the language. We've delegated other style choices like requiring `self.` or brace formatting to linters; why does this one need to be legislated by the compiler?

-Joe

···

On May 13, 2016, at 7:04 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

No. Tell us what you *really* think of the style. Don't hold back.[1]

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

I wouldn't object to this restriction. I cannot think of a situation where using ",)" -- that is the comma adjacent to a closing parenthesis -- makes sense for any reason previously enumerated in support of this proposal.

67

For what it's worth, I'm very much in favour of this idea of allowing line breaks instead of commas in lists.

I'm neutral on trailing commas in the parameter lists & tuples. I can the the consistency argument, but think that trailing commas should only be used for multi-line lists; in which case a new line character is better as there would be less visual clutter without any of the commas.

Regards,

Rob...

···

On 13 May 2016, at 07:22, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

It seems like all problems could be solved by allowing line-break instead of comma in list:

68

I forgot to add I like this style particularly as it matches how the type is declared (below). There’s a symmetry between them all. Obviously each var in a struct doesn’t need a comma between it, so it would be nice to not have to type them in the other cases too!

public struct ImageGraphic : GraphicType {
  var imageSource: ImageSource
  var width: Dimension?
  var height: Dimension?
}

···

On 13 May 2016, at 4:22 PM, Vladimir.S <svabox@gmail.com> wrote:

It seems like all problems could be solved by allowing line-break instead of comma in list:

  public init(source: JSONObjectDecoder) throws {
    try self.init(
      imageSource: source.decode("imageSource")
      width: source.decodeOptional("width")
      height: source.decodeOptional("height")
    )
  }
  
  public func toJSON() -> JSON {
    return .ObjectValue([
      "imageSource": imageSource.toJSON()
      "width": width.toJSON()
      "height": height.toJSON()
    ])
  }

Shouldn't we move in that direction? Probably in addition to allow trailing comma just to allow one to use his/her preferable formatting

On 13.05.2016 9:07, Patrick Smith via swift-evolution wrote:

I do it quite a lot, especially for initialising structs, enums. I use it to get the same benefits as a switch statement spread over several lines.

I think it’s often good to liberally apply new lines, as it aids legibility.

Here some sample code of mine using it:

extension ImageGraphic : JSONObjectRepresentable {
  public init(source: JSONObjectDecoder) throws {
    try self.init(
      imageSource: source.decode("imageSource"),
      width: source.decodeOptional("width"),
      height: source.decodeOptional("height")
    )
  }
  
  public func toJSON() -> JSON {
    return .ObjectValue([
      "imageSource": imageSource.toJSON(),
      "width": width.toJSON(),
      "height": height.toJSON()
    ])
  }
}

On 13 May 2016, at 3:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
  - y: 1
  + y: 1,
  + z: 2
   )

Trailing commas avoid this:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
     y: 1,
  + z: 2,
   )

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

The standard library already uses this style for function parameters, modulo the trailing comma, and I certainly prefer it to:
  

  --- a.swift
  +++ a.swift
   foo( x: 0
      , y: 1
  + , z: 2
      )

I agree that this is even worse, but I also haven’t seen this used in Swift code. Have you? Swift’s strictness with argument labels makes any of this pretty unappealing to use.

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

-Chris
_______________________________________________
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

69

I am, +1 on allowing new lines instead of commas. I suggest you pursue a proposal on that.

Unfortunately I have no ability for this right now, so someone who is interested in this could take the idea and create a 'formal' proposal.

I am also +1 on the current proposal because it exists and will be pretty useful in some cases and I can't predict how long it might be until such a new line proposal would be approved. I also think that the choice between them should be a style choice, not one made by the language (as with semicolon) and if anyone chooses commas they should have the utility of the current proposal available to them.

Don't you feel like this proposal(SE-0084) should be extended to list of generic types at least, or even to allow trailing comma in any comma-separated list in Swift? I.e. you are saying +1, but probably the exact proposal should be improved to have your +1.

Probably (if this is allowed) the author of this proposal (SE-0084) can add 'line-break separator feature' to his/her proposal and generalize the rule of trailing comma/line-breaks for any comma-separated list in Swift?

As I can see, the proposal SE-0084 'per se' has more negative comments than positive(even if some from @apple.com supports it) and I feel like extended proposal can have more support.

···

On 13.05.2016 16:32, Matthew Johnson wrote:

Sent from my iPad

On May 13, 2016, at 1:24 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

IMO If we were *really* concerned about this, we should just allow line-break as separator in comma-separated lists.

On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote:
If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

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

70

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

No. Tell us what you *really* think of the style. Don't hold back.[1]

Gave me a great smile at the end of a long day... Reminded me of how in the show "Yes Minister", the main character chooses an rather insignificant topics to *send a strong message* to the public opinion, and lands the job of england's next prime minister.

···

On May 13, 2016, at 4:04 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

I wouldn't object to this restriction. I cannot think of a situation where using ",)" -- that is the comma adjacent to a closing parenthesis -- makes sense for any reason previously enumerated in support of this proposal.

-- E

[1] "Swift is an opinionated language" - C. Lattner

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

71

Tino, I believe you can start just with [Draft]... thread where you can present the draft of your proposal. Then, after you'll get opinions and after the draft will be polished, you can form an 'official' proposal.

For now I didn't hear if someone else wanted to create that proposal. So I don't see any barrier for you to do this(if you want).

As for proposal itself. Yes, I also think almost all of SE-0084 goals could be archived in your proposal.
But, personally I believe new proposal should introduce newlines as separators for any comma-separated list, not limited by funcs/typles but also array/dicts/generic type list etc. If something will be hard/imposible to implement - core team can accept the proposal with some exceptions after the review.

···

On 15.05.2016 13:18, Tino Heth wrote:

Tino, would you like to form an 'official' proposal for this(newlines
as separators) feature? As I can see, there is a much support in
community for this idea, but no one said yet he/she will create a
proposal for this.(or I just missed this)

I feel honored, but I guess there are others (native speaker, closer
relation to the core team...) who are better suited than me... On the
other hand, I lack fear of seeing a proposal rejected ;-), so as long as
deeper thinking doesn't reveal any downsides, I don't mind spending some
hours and putting my name on the pull request. Afaics, there are no
plans to change SE-0084 to at least add "making commas optional if
followed by a newline" as an alternative, so the first step would be a
separate thread ("Newlines as item separators in lists"?) — but as all
examples in the proposal use commas followed by newlines, I think all of
its goals could be archived

72

I am, +1 on allowing new lines instead of commas. I suggest you pursue a proposal on that.

Unfortunately I have no ability for this right now, so someone who is interested in this could take the idea and create a 'formal' proposal.

I am also +1 on the current proposal because it exists and will be pretty useful in some cases and I can't predict how long it might be until such a new line proposal would be approved. I also think that the choice between them should be a style choice, not one made by the language (as with semicolon) and if anyone chooses commas they should have the utility of the current proposal available to them.

Don't you feel like this proposal(SE-0084) should be extended to list of generic types at least, or even to allow trailing comma in any comma-separated list in Swift? I.e. you are saying +1, but probably the exact proposal should be improved to have your +1.

I have no opinion on that. I don't object to it being done in the name of consistency but can't think of any actual use cases either.

Probably (if this is allowed) the author of this proposal (SE-0084) can add 'line-break separator feature' to his/her proposal and generalize the rule of trailing comma/line-breaks for any comma-separated list in Swift?

That feels like a separate proposal to me.

···

Sent from my iPad

On May 13, 2016, at 9:19 AM, Vladimir.S <svabox@gmail.com> wrote:

On 13.05.2016 16:32, Matthew Johnson wrote:

As I can see, the proposal SE-0084 'per se' has more negative comments than positive(even if some from @apple.com supports it) and I feel like extended proposal can have more support.

Sent from my iPad

On May 13, 2016, at 1:24 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

IMO If we were *really* concerned about this, we should just allow line-break as separator in comma-separated lists.

On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote:
If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

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

73

I forgot to add I like this style particularly as it matches how the type is declared (below). There’s a symmetry between them all. Obviously each var in a struct doesn’t need a comma between it, so it would be nice to not have to type them in the other cases too!

public struct ImageGraphic : GraphicType {
   var imageSource: ImageSource
   var width: Dimension?
   var height: Dimension?
}

Hate to admit it (i write my code such that i can use ", xxxx" as a search pattern, especially with editors/IDEs that have a poot level of understanding of what I am typing - Did I mention somewhere this idea of a new @string_literal("text/json") attribute to help them make some sense of what those magic quoted-holes contain??!), but I actually am growing fonder of this by the day... I can even find it logical considering other grammar-fragments use the same heuristic to get rid of their own separation markers (like ;)

···

On May 13, 2016, at 8:31 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org> wrote:

On 13 May 2016, at 4:22 PM, Vladimir.S <svabox@gmail.com> wrote:

It seems like all problems could be solved by allowing line-break instead of comma in list:

   public init(source: JSONObjectDecoder) throws {
       try self.init(
           imageSource: source.decode("imageSource")
           width: source.decodeOptional("width")
           height: source.decodeOptional("height")
       )
   }
   
   public func toJSON() -> JSON {
       return .ObjectValue([
           "imageSource": imageSource.toJSON()
           "width": width.toJSON()
           "height": height.toJSON()
       ])
   }

Shouldn't we move in that direction? Probably in addition to allow trailing comma just to allow one to use his/her preferable formatting

On 13.05.2016 9:07, Patrick Smith via swift-evolution wrote:
I do it quite a lot, especially for initialising structs, enums. I use it to get the same benefits as a switch statement spread over several lines.

I think it’s often good to liberally apply new lines, as it aids legibility.

Here some sample code of mine using it:

extension ImageGraphic : JSONObjectRepresentable {
   public init(source: JSONObjectDecoder) throws {
       try self.init(
           imageSource: source.decode("imageSource"),
           width: source.decodeOptional("width"),
           height: source.decodeOptional("height")
       )
   }
   
   public func toJSON() -> JSON {
       return .ObjectValue([
           "imageSource": imageSource.toJSON(),
           "width": width.toJSON(),
           "height": height.toJSON()
       ])
   }
}

On 13 May 2016, at 3:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

   --- a.swift
   +++ a.swift
    foo(
      x: 0,
   - y: 1
   + y: 1,
   + z: 2
    )

Trailing commas avoid this:

   --- a.swift
   +++ a.swift
    foo(
      x: 0,
      y: 1,
   + z: 2,
    )

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

The standard library already uses this style for function parameters, modulo the trailing comma, and I certainly prefer it to:
   

   --- a.swift
   +++ a.swift
    foo( x: 0
       , y: 1
   + , z: 2
       )

I agree that this is even worse, but I also haven’t seen this used in Swift code. Have you? Swift’s strictness with argument labels makes any of this pretty unappealing to use.

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

-Chris
_______________________________________________
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

74

Sent from my iPad

I am, +1 on allowing new lines instead of commas. I suggest you pursue a proposal on that.

Unfortunately I have no ability for this right now, so someone who is interested in this could take the idea and create a 'formal' proposal.

I am also +1 on the current proposal because it exists and will be pretty useful in some cases and I can't predict how long it might be until such a new line proposal would be approved. I also think that the choice between them should be a style choice, not one made by the language (as with semicolon) and if anyone chooses commas they should have the utility of the current proposal available to them.

Don't you feel like this proposal(SE-0084) should be extended to list of generic types at least, or even to allow trailing comma in any comma-separated list in Swift? I.e. you are saying +1, but probably the exact proposal should be improved to have your +1.

I have no opinion on that. I don't object to it being done in the name of consistency but can't think of any actual use cases either.

Probably (if this is allowed) the author of this proposal (SE-0084) can add 'line-break separator feature' to his/her proposal and generalize the rule of trailing comma/line-breaks for any comma-separated list in Swift?

That feels like a separate proposal to me.

I agree, allowing commas to be elided at line breaks is an interesting direction that deserves its own discussion. One problem that immediately comes to my mind is commas in generic parameter lists. If commas aren't required in generic parameter lists, it becomes even more challenging to disambiguate with less-than/greater-than expressions at top level, compromising our ability to shed `.self` for this purpose.

-Joe

···

On May 13, 2016, at 7:32 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 13, 2016, at 9:19 AM, Vladimir.S <svabox@gmail.com> wrote:

On 13.05.2016 16:32, Matthew Johnson wrote:

As I can see, the proposal SE-0084 'per se' has more negative comments than positive(even if some from @apple.com supports it) and I feel like extended proposal can have more support.

Sent from my iPad

On May 13, 2016, at 1:24 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

IMO If we were *really* concerned about this, we should just allow line-break as separator in comma-separated lists.

On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote:
If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

_______________________________________________
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

75

Mostly because I'm trying to play nice and get Chris to reconsider. I'd like to get the feature, I'm willing to compromise on the technicalities.
Having it would make my coding life significantly easier and if a little micromanagement is involved, I'm not terribly fussed. When I need trailing
commas, it's always at the ends of lines anyway.

But since I don't want to undercut you, so I'd much prefer to step back and defer to your judgement on this.

-- E

···

On May 13, 2016, at 11:29 AM, Joe Groff <jgroff@apple.com> wrote:

On May 13, 2016, at 7:04 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

No. Tell us what you *really* think of the style. Don't hold back.[1]

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

I wouldn't object to this restriction. I cannot think of a situation where using ",)" -- that is the comma adjacent to a closing parenthesis -- makes sense for any reason previously enumerated in support of this proposal.

I don't see why we need to micromanage the situations where trailing commas are allowed. That's just unnecessarily increasing the fractal complexity of the language. We've delegated other style choices like requiring `self.` or brace formatting to linters; why does this one need to be legislated by the compiler?

-Joe

76

Support. *all or nothing* :-)

···

On 13.05.2016 20:29, Joe Groff via swift-evolution wrote:

I don't see why we need to micromanage the situations where trailing commas are allowed. That's just unnecessarily increasing the fractal complexity of the language. We've delegated other style choices like requiring `self.` or brace formatting to linters; why does this one need to be legislated by the compiler?

77

Sorry, I replied to you, but my comments were more directed toward Chris.

-Joe

···

On May 13, 2016, at 10:46 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 13, 2016, at 11:29 AM, Joe Groff <jgroff@apple.com> wrote:

On May 13, 2016, at 7:04 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

No. Tell us what you *really* think of the style. Don't hold back.[1]

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

I wouldn't object to this restriction. I cannot think of a situation where using ",)" -- that is the comma adjacent to a closing parenthesis -- makes sense for any reason previously enumerated in support of this proposal.

I don't see why we need to micromanage the situations where trailing commas are allowed. That's just unnecessarily increasing the fractal complexity of the language. We've delegated other style choices like requiring `self.` or brace formatting to linters; why does this one need to be legislated by the compiler?

-Joe

Mostly because I'm trying to play nice and get Chris to reconsider. I'd like to get the feature, I'm willing to compromise on the technicalities.

78

Having used, more or less continuously for my 20 years as a professional
programmer, both a language that allows trailing commas and one that does
not, I come down pretty strongly on the side of allowing trailing commas
(for all the reasons already stated in this thread). If it means requiring
a newline after the last comma to make some people feel better about it, so
be it.

-John

···

On Fri, May 13, 2016 at 1:46 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

On May 13, 2016, at 11:29 AM, Joe Groff <jgroff@apple.com> wrote:

On May 13, 2016, at 7:04 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

You’re arguing that you want to read Swift code written like this?

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code
commonly doing it. I’m not sure that we want to encourage it either.

No. Tell us what you *really* think of the style. Don't hold back.[1]

If we were really concerned about this, a narrower way to solve the same
problem would be to allow a comma before the ), but *only* when there is a
newline between them. I still don’t see why we’d want to encourage this
though.

I wouldn't object to this restriction. I cannot think of a situation where
using ",)" -- that is the comma adjacent to a closing parenthesis -- makes
sense for any reason previously enumerated in support of this proposal.

I don't see why we need to micromanage the situations where trailing
commas are allowed. That's just unnecessarily increasing the fractal
complexity of the language. We've delegated other style choices like
requiring `self.` or brace formatting to linters; why does this one need to
be legislated by the compiler?

-Joe

Mostly because I'm trying to play nice and get Chris to reconsider. I'd
like to get the feature, I'm willing to compromise on the technicalities.
Having it would make my coding life significantly easier and if a little
micromanagement is involved, I'm not terribly fussed. When I need trailing
commas, it's always at the ends of lines anyway.

But since I don't want to undercut you, so I'd much prefer to step back
and defer to your judgement on this.

-- E

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