This is a pretty obvious post but perhaps writing it will stop me falling prey to this issue.
When I'm debugging and I know that some code executed in a function is not to blame but is noisy in terms of what it causes to happen, etc. I'll often just prevent it from being executed in order to simplify the system, e.g.
func foo()
{
/*
f()
g()
h()
// Do lots of other things...
*/
}
Sometimes, I like to be quicker so I just put in an early return statement, i.e.,
func foo()
{
return
f()
g()
h()
// Do lots of other things...
}
I must also go temporarily warning blind and ignore the following:
The effect of this is that rather than prevent everything after the return statement from executing it as per the warning, the return statement takes f() as its argument and explicitly calls it returning its value, though not executing the remaining functions. In this case, as foo() (and f() though it's not shown) is void, that is nothing. In fact if foo() or f() had non-void return types, this wouldn't compile.
The fix is easy. Just put a semi-colon after the return.
func foo()
{
return;
f()
g()
h()
// Do lots of other things...
}
I use this 'technique' when I'm debugging C++ where this works fine. This is slightly interesting as C++ has the same semantics. The following C++ code has the same problem as the Swift, in that this code also invokes f() as its return value.
void foo()
{
return
f();
g();
g();
}
I guess the reason it's not an issue with C++ (as much or at all) is that my muscle memory or something else is always wanting to terminate lines with semi-colons so the natural way to write the return would be 'return;' whereas in Swift without the semi-colon requirement, it's natural not to hence this issue becomes slightly more prevalent.
