[blinks]

You can even go farther than that -- return true on success, and anything else on failure, and you get the semantics this person wants. If the results should be saved, that should generally be done outside the if condition anyway.

[regularfry]

Returning true on success is less useful because in general it's the details of a successful result that you want to operate on. It's less common (but not by any means rare, I admit) for the "happy path" through code to be concerned with details of the error.

> If the results should be saved, that should generally be done outside the if condition anyway.

That's as may be. This is one of those areas where the language is guiding you towards a specific code pattern rather than explicitly preventing something, and I just don't think in this case the guidance is helpful or warranted. I think it's a side-effect of a workaround for a bug in the compilation target, and that's not a good thing to expose at the language spec level.