[swift-evolution] commas optional

Mike Kluev mike.kluev at gmail.com
Sun Oct 15 10:32:10 CDT 2017

on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner <clattner at nondot.org>

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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171015/682942cb/attachment.html>

More information about the swift-evolution mailing list