Sub-optimal or not, I’d call that unexpected behavior. Does it make more sense to ensure return doesn’t take an argument in a function returning void?
> On Jun 6, 2016, at 10:00 , Jens Alfke via swift-users <swift-users@swift.org> > wrote: > > Someone on another forum (not directly related to Swift) just mentioned > running into a confusing situation where they had added an early `return` to > a method for testing purposes, in order to disable the code following it: > > func myFunc() { > // some code > return > cache.removeAll() > // more code that is now skipped. > } > > Unexpectedly, the line following the `return` still got executed, so "I > couldn't figure out why my cache kept getting zapped.” > > Turns out the Swift parser is interpreting this as `return > cache.removeAll()`, which works because that expression returns void, which > matches the function’s return type. > > This seems like a case where the parser is playing by the rules, but the > result is not what a human would expect. It would be better for a `return` on > a line by itself to be parsed as a complete statement, without continuing to > the next line. Is this already a known issue? > > —Jens > > PS: I’m sure someone will point out that adding an early return like this is > sub-optimal, and the compiler could warn that the code following is > unreachable. Which is true, and I use comments to disable code in situations > like this. But I’m sure this developer’s not the only one who adds `return` > instead. > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users