My comment was about using if blocks as opposed to early returns. I.e. where the nested ifs run exhaustively and return afterwards.
Also, obviously deep nested ifs aren't good, so I wasn't advocating them - I just think it's better to fix them by splitting functions or simplifying control flow, than by adding early returns.
So it is more about multiple returns, versus setting some local return variable and returning in one place.
However, setting that return variable can be recognized as a simulated return. If we know that after "ret = 42", there are no other state changes; that the whole if/else mess will drop out to the end where there is a "return ret", then we can just read it as "return 42".
Or where it produces an effect (or effect group) in every case just before returning, without multiple effects interspersed among multiple condition tests.
My comment was about using if blocks as opposed to early returns. I.e. where the nested ifs run exhaustively and return afterwards.
Also, obviously deep nested ifs aren't good, so I wasn't advocating them - I just think it's better to fix them by splitting functions or simplifying control flow, than by adding early returns.