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
···
on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner <clattner@nondot.org> wrote:
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 <swift-evolution@swift.org> wrote:
on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner <clattner@nondot.org <mailto:clattner@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
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.
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 <dave@yost.com> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner <clattner@nondot.org <mailto:clattner@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
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.
<tab-character> return
<tab-character> foo() // visually no indent, warning
<tab-character> return
<nnnn-spaces> 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
···
On 16 October 2017 at 01:20, Dave Yost <Dave@yost.com> 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.