[swift-evolution] commas optional

[Chris Lattner]

> On Oct 13, 2017, at 10:43 AM, Jarod Long via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Ahh, yeah, that does seem like a much trickier case to avoid breaking. My instinct says it's still possible to avoid, but maybe not without lots of complexity.

We already have whitespace sensitive rules to handle this.  There is no fundamental implementation difference that I see between separating the elements of lists (which are expressions) and the elements of statements (which can be expressions):

func foo() -> Int { … }

func statements() {
  foo()
  foo()
}

let list = [
  foo()
  foo()
]

That said, I still believe that it would be premature to "syntax optimize" this at this point in Swift’s evolution.

-Chris



> 
> Jarod
> 
> On Oct 12, 2017, 16:21 -0700, Xiaodi Wu <xiaodi.wu at gmail.com>, wrote:
>> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I don't really expect this sort of syntactic sugar to be popular enough to make it through swift-evolution, and I don't think it's worth the distraction from more important priorities at this time, but for what it's worth, I've enjoyed this feature in other languages that support it. It plays a small part in making code more focused by eliminating unnecessary syntax.
>> 
>> I could be wrong, but I'm not so sure that this would actually be source breaking. Even if you have something like this:
>> 
>> let points = [
>>     Point(
>>         x: 1.0,
>>         y: 2.0
>>     ),
>>     Point(
>>         x: 3.0,
>>         y: 4.0
>>     )
>> ]
>> 
>> Proper implementation of this feature wouldn't suddenly interpret `Point(` as its own element.
>> 
>> There are those of us who respect the 80-character line and break expressions across lines:
>> 
>> let x = [
>>   NSVeryVeryVeryLongType
>>     .veryVeryVeryLongProperty +
>>       NSVeryVeryVeryLongType2
>>         .veryVeryVeryLongProperty2,
>> ]
>> 
>> It would be a pleasant surprise if a grammar with optional commas can avoid blowing up existing code; I'm quite doubtful.
>> 
>> 
>> On Oct 12, 2017, 12:23 -0700, Josh Parmenter via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>, wrote:
>>> 
>>> 
>>> On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org><mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> wrote:
>>> 
>>> a semicolon is a purely syntactic delimiter, the comma on the other hand corresponds to physical elements in a collection. I think the two are more different than you suggest.
>>> 
>>> 
>>> I very much agree^
>>> 
>>> Josh
>>> 
>>> 
>>> 
>>> Joshua Parmenter | Engineering Lead, Apple Technologies
>>> 
>>> T 248 777 7777 <tel:(248)%20777-7777>
>>> C 206 437 1551 <tel:(206)%20437-1551>
>>> F 248 616 1980 <tel:(248)%20616-1980>
>>> www.vectorform.com <http://www.vectorform.com/><http://www.vectorform.com/ <http://www.vectorform.com/>
>>> 
>>> Vectorform
>>> 2211 5th Ave Suite 201
>>> Seattle, WA 98121 USA
>>> 
>>> Think Tank. Lab. Studio.
>>> We invent digital products and experiences.
>>> 
>>> SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171013/8b20d403/attachment.html>