Re: [swift-evolution] commas optional

[Mike Kluev via swift-evolution]

On 16 October 2017 at 01:20, Dave Yost  wrote:

> Nuance:
>
> Compiler says:
> Expression following ‘return’ is treated as an argument of the 'return
> '.
> unless foo() is indented by at least one space. Then there is no
> complaint.
>

to have more fun try this:

 return
 foo()  // visually no indent, warning

 return
 foo()  // no warning. but visually it is the same as above.

where n is the same number of spaces as in your tab-character

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

Re: [swift-evolution] commas optional

[Dave Yost via swift-evolution]

Nuance:

Compiler says:
Expression following ‘return’ is treated as an argument of the 'return'.
unless foo() is indented by at least one space. Then there is no complaint.

> On 2017-10-15, at 4:32 PM, Dave Yost  wrote:
> 
> Very cool!
> 
> func foo() -> Int { return 17 }
> 
> func bug1() -> Int {
> return
> foo()  // Compiler says: Expression following ‘return'
>//is treated as an argument of the 'return'.
> }
> 
> var x = 0
> 
> func bug2() {
> return x = 4 // not even a warning – should be an error
> }
> 
> print(bug1()) // prints 17
> bug2()
> 
> Dave
> 
> bug1() suggests that return be one of perhaps a set of special cases where 
> line wrap is illegal.
> 
> bug2() is a compiler bug IMO.
> 
>> On 2017-10-15, at 8:32 AM, Mike Kluev via swift-evolution 
>> > wrote:
>> 
>> on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner > > wrote:
>> 
>> 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()
>> ]
>> 
>> i was beaten by these optional semicolons...
>> 
>> override func viewDidLoad() {
>>  super.viewDidLoad()
>>  return  // put it ad-hoc to temporarily circumvent the rest of the code
>>  
>>  someView = SomeView(frame: view.bounds) // *
>>  view.addSubview(someView)   // **
>>  ...
>> }
>>  
>> so i put that ad-hoc return statement to circumvent the rest of the code 
>> temporarily. of course i didn't put a semicolon after "return" as that skill 
>> was long lost. to my surprise the app crashed, and nowhere else but in the 
>> code that i thought was disabled...
>> 
>> further investigation showed that in this case compiler was treating the 
>> statement after return which happened to have the matching type “Void” as 
>> part of return statement.
>> 
>> should the function return type was, say, Int - that wouldn’t happen. or 
>> should the next statement was of a different type - that wouldn’t happen. in 
>> this case i was just “lucky”. here semantic information (matching vs non 
>> matching types) is clearly "aiding" syntax parsing and sometimes it leads to 
>> a surprising results.
>> 
>> there was a warning on the * line:
>> “warning: expression following 'return' is treated as an argument of the 
>> 'return’”
>> 
>> and another warning on the ** line:
>> “warning: code after 'return' will never be executed”
>> 
>> as i was prepared to get the warning about the code being unused in the 
>> first place, i didn’t pay too much attention to the exact wording of that 
>> warning... and was beaten by it.
>> 
>> Mike
>> 
>> ___
>> 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

Re: [swift-evolution] commas optional

[Dave Yost via swift-evolution]

Very cool!

func foo() -> Int { return 17 }

func bug1() -> Int {
return
foo()  // Compiler says: Expression following ‘return'
   //is treated as an argument of the 'return'.
}

var x = 0

func bug2() {
return x = 4 // not even a warning – should be an error
}

print(bug1()) // prints 17
bug2()

Dave

bug1() suggests that return be one of perhaps a set of special cases where line 
wrap is illegal.

bug2() is a compiler bug IMO.

> On 2017-10-15, at 8:32 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner  > wrote:
> 
> 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()
> ]
> 
> i was beaten by these optional semicolons...
> 
> override func viewDidLoad() {
>   super.viewDidLoad()
>   return  // put it ad-hoc to temporarily circumvent the rest of the code
>   
>   someView = SomeView(frame: view.bounds) // *
>   view.addSubview(someView)   // **
>   ...
> }
>   
> so i put that ad-hoc return statement to circumvent the rest of the code 
> temporarily. of course i didn't put a semicolon after "return" as that skill 
> was long lost. to my surprise the app crashed, and nowhere else but in the 
> code that i thought was disabled...
> 
> further investigation showed that in this case compiler was treating the 
> statement after return which happened to have the matching type “Void” as 
> part of return statement.
> 
> should the function return type was, say, Int - that wouldn’t happen. or 
> should the next statement was of a different type - that wouldn’t happen. in 
> this case i was just “lucky”. here semantic information (matching vs non 
> matching types) is clearly "aiding" syntax parsing and sometimes it leads to 
> a surprising results.
> 
> there was a warning on the * line:
> “warning: expression following 'return' is treated as an argument of the 
> 'return’”
> 
> and another warning on the ** line:
> “warning: code after 'return' will never be executed”
> 
> as i was prepared to get the warning about the code being unused in the first 
> place, i didn’t pay too much attention to the exact wording of that 
> warning... and was beaten by it.
> 
> Mike
> 
> ___
> 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

Re: [swift-evolution] commas optional

[Mike Kluev via swift-evolution]

on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner 
wrote:

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()
> ]
>

i was beaten by these optional semicolons...

override func viewDidLoad() {
super.viewDidLoad()
return // put it ad-hoc to temporarily circumvent the rest of the code
someView = SomeView(frame: view.bounds) // *
view.addSubview(someView) // **
...
}
so i put that ad-hoc return statement to circumvent the rest of the code
temporarily. of course i didn't put a semicolon after "return" as that
skill was long lost. to my surprise the app crashed, and nowhere else but
in the code that i thought was disabled...

further investigation showed that in this case compiler was treating the
statement after return which happened to have the matching type “Void” as
part of return statement.

should the function return type was, say, Int - that wouldn’t happen. or
should the next statement was of a different type - that wouldn’t happen.
in this case i was just “lucky”. here semantic information (matching vs non
matching types) is clearly "aiding" syntax parsing and sometimes it leads
to a surprising results.

there was a warning on the * line:
“warning: expression following 'return' is treated as an argument of the
'return’”

and another warning on the ** line:
“warning: code after 'return' will never be executed”

as i was prepared to get the warning about the code being unused in the
first place, i didn’t pay too much attention to the exact wording of that
warning... and was beaten by it.

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

Re: [swift-evolution] commas optional

[Chris Lattner via swift-evolution]

> On Oct 13, 2017, at 10:43 AM, Jarod Long via swift-evolution 
>  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 , wrote:
>> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution 
>> > 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 
>> >, wrote:
>>> 
>>> 
>>> On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
>>> >> >> >> 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  
>>> C 206 437 1551 
>>> F 248 616 1980 
>>> 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@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

Re: [swift-evolution] commas optional

[Jarod Long via swift-evolution]

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.

Jarod

On Oct 12, 2017, 16:21 -0700, Xiaodi Wu , wrote:
> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution 
>  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 
> > > , wrote:
> > > >
> > > >
> > > > On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> > > > > 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 
> > > > C 206 437 1551
> > > > F 248 616 1980
> > > > 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@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

Re: [swift-evolution] commas optional

[Chris Lattner via swift-evolution]

Hi Dave,

I agree with you that this is an analogous technical problem to semicolon 
inference, and that Swift has a well developed solution for it which would 
probably work well enough.

That said, this is a pure sugar proposal, one which can make future evolution 
more difficult.  Getting this into Swift 5 will be very very difficult to 
justify, even if the community somehow agreed that it was the right thing to 
do.  It is just the conservatively correct default to say “no” to these sorts 
of changes now, because there are other bigger moving pieces that have to be 
sorted first.

-Chris



> On Oct 12, 2017, at 11:50 AM, Dave Yost via swift-evolution 
>  wrote:
> 
> 
> Speaking as a huge fan of optional semicolons...
> 
> 
> This seems clear:
> 
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
> 
> and so it occurred to me that this should hold:
> 
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
> 
>   ∴  A comma after the last array element on a line should be optional.
> 
> and these should be legal Swift:
> 
>   let list = [
>   1
>   2
>   ]
> 
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
> 
> equivalent to:
> 
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
> 
> 
> Or, as the Language Reference would say:
> 
> A semicolon (;) can optionally appear after any statement and is used to 
> separate multiple statements if they appear on the same line.
> 
> A comma (,) can optionally appear after any element of an array literal and 
> is used to separate multiple elements if they appear on the same line.
> 
> Or:
> 
> A semicolon (;) separates statements but is optional after the last statement 
> on a line.
> 
> A comma (,) separates elements of an array literal but is optional after the 
> last element on a line.
> 
> 
> ___
> 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

Re: [swift-evolution] commas optional

[Kelvin Ma via swift-evolution]

On Thu, Oct 12, 2017 at 6:20 PM, Xiaodi Wu  wrote:

> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution <
> swift-evolution@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.
>
>
>
An argument against optional commas,, or an indictment of overly verbose
Foundation APIs… 樂樂樂
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] commas optional

[Xiaodi Wu via swift-evolution]

On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution <
swift-evolution@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@swift.org>, wrote:
>
>
>
> On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution <
> swift-evolution@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  <(248)%20777->
> C 206 437 1551 <(206)%20437-1551>
> F 248 616 1980 <(248)%20616-1980>
> 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@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

Re: [swift-evolution] commas optional

[Dave Yost via swift-evolution]

> On 2017-10-12, at 12:03 PM, Xiaodi Wu  wrote:
> 
> Single elements can legally span multiple lines; this would be hugely source 
> breaking. What problem are you trying to solve?

The same problem that is solved by the precedent of semicolons being optional 
(clutter). I don’t see anything substantive about the analogy that does not 
hold.

Plus there is the meta-problem of inconsistency, where the analogy is apt but 
not expressed in the language.

> On Thu, Oct 12, 2017 at 13:50 Dave Yost via swift-evolution 
> > wrote:
> 
> Speaking as a huge fan of optional semicolons...
> 
> 
> This seems clear:
> 
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
> 
> and so it occurred to me that this should hold:
> 
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
> 
>   ∴  A comma after the last array element on a line should be optional.
> 
> and these should be legal Swift:
> 
>   let list = [
>   1
>   2
>   ]
> 
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
> 
> equivalent to:
> 
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
> 
> 
> Or, as the Language Reference would say:
> 
> A semicolon (;) can optionally appear after any statement and is used to 
> separate multiple statements if they appear on the same line.
> 
> A comma (,) can optionally appear after any element of an array literal and 
> is used to separate multiple elements if they appear on the same line.
> 
> Or:
> 
> A semicolon (;) separates statements but is optional after the last statement 
> on a line.
> 
> A comma (,) separates elements of an array literal but is optional after the 
> last element on a line.
> 
> 
> ___
> 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

Re: [swift-evolution] commas optional

[Jarod Long via swift-evolution]

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.

Jarod

On Oct 12, 2017, 12:23 -0700, Josh Parmenter via swift-evolution 
, wrote:
>
>
> On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> > 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 
> C 206 437 1551
> F 248 616 1980
> 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@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

Re: [swift-evolution] commas optional

[Josh Parmenter via swift-evolution]

On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> 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 
C 206 437 1551
F 248 616 1980
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] commas optional

[Kelvin Ma via swift-evolution]

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.

On Thu, Oct 12, 2017 at 1:50 PM, Dave Yost via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Speaking as a huge fan of optional semicolons...
>
>
> This seems clear:
>
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
>
> and so it occurred to me that this should hold:
>
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
>
>   ∴  A comma after the last array element on a line should be optional.
>
> and these should be legal Swift:
>
>   let list = [
>   1
>   2
>   ]
>
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
>
> equivalent to:
>
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
>
>
> Or, as the Language Reference would say:
>
> A semicolon (;) can optionally appear after any statement and is used to
> separate multiple statements if they appear on the same line.
>
>
> A comma (,) can optionally appear after any element of an array literal
> and is used to separate multiple elements if they appear on the same line.
>
>
> Or:
>
> A semicolon (;) separates statements but is optional after the last
> statement on a line.
>
>
> A comma (,) separates elements of an array literal but is optional after
> the last element on a line.
>
>
>
>
> ___
> 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

Re: [swift-evolution] commas optional

[Xiaodi Wu via swift-evolution]

Single elements can legally span multiple lines; this would be hugely
source breaking. What problem are you trying to solve?

On Thu, Oct 12, 2017 at 13:50 Dave Yost via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Speaking as a huge fan of optional semicolons...
>
>
> This seems clear:
>
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
>
> and so it occurred to me that this should hold:
>
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
>
>   ∴  A comma after the last array element on a line should be optional.
>
> and these should be legal Swift:
>
>   let list = [
>   1
>   2
>   ]
>
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
>
> equivalent to:
>
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
>
>
> Or, as the Language Reference would say:
>
> A semicolon (;) can optionally appear after any statement and is used to
> separate multiple statements if they appear on the same line.
>
>
> A comma (,) can optionally appear after any element of an array literal
> and is used to separate multiple elements if they appear on the same line.
>
>
> Or:
>
> A semicolon (;) separates statements but is optional after the last
> statement on a line.
>
>
> A comma (,) separates elements of an array literal but is optional after
> the last element on a line.
>
>
>
> ___
> 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] commas optional

[Dave Yost via swift-evolution]

Speaking as a huge fan of optional semicolons...


This seems clear:

 semicolon : sequence of statements
  :: comma : sequence of elements in an array literal

and so it occurred to me that this should hold:

 A semicolon : the last statement on a line.
  :: A comma : the last array element on a line.

  ∴  A comma after the last array element on a line should be optional.

and these should be legal Swift:

  let list = [
  1
  2
  ]

  let dict = [
  1 : 2
  2 : 3
  ]

equivalent to:

  let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]


Or, as the Language Reference would say:

A semicolon (;) can optionally appear after any statement and is used to 
separate multiple statements if they appear on the same line.

A comma (,) can optionally appear after any element of an array literal and is 
used to separate multiple elements if they appear on the same line.

Or:

A semicolon (;) separates statements but is optional after the last statement 
on a line.

A comma (,) separates elements of an array literal but is optional after the 
last element on a line.


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