on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner <clatt...@nondot.org>
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
