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 <[email protected]> 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 
>>> <[email protected]> wrote:
>>> 
>>> On May 12, 2016, at 4:50 PM, Joe Groff <[email protected]> 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
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to