>>107666083
if(!foo()) return
x = fooX()
if(!goo()) return
y = gooY(x)
... // lots of such guards interleaved with assignments
z - hooZ(x, y, ...)
return actualBusinessLogic(x, y, ..., z)
Not saying this can't be written another way, but it's always possible to transform code with early returns into code without them, it's just certain situations are extremely verbose or awkward without early returns. It's really about ergonomics. It's the same situation with `continue` in lua. In certain situations it forces you to write very awkward and difficult to understand loops in the best case. Whereas having continue statements makes it much more obvious
And keep in mind this is the case with *literally* every programming language construct: it's literally all about ergonomics; that's why we have high level languages -- so we don't have to write assembly for everything. But, of course, that doesn't mean we should only use super high level language, rather that we just use the tools that are most appropriate for each individual situations. Lot's of language feature variety plus high skill and knowledge levels seems to make for the best cases