I'm not sure what you mean? In my experience, returns are generally grouped at the top.

void f(int x)
{
  if (x < 0)
    return;

  do;
  if (do.error)
    return;

  some;
  work;
}

In lieu of any hinting, the if is assumed true; so the compiler will branch over the return in the nominal case.

You would need to write this to fix that bad prediction:

void f(int x)
{
  if (x >= 0)
  {
    do;
    if (!do.error)
    {
      some;
      work;
    }
  }
}

You can see how the function body will accumulate unmitigated scopes now. That's just straight up bad code. (Linus would sack me on the spot if I wrote that!)
It's not at all unlikely to find functions that have several such checks in series... I won't write code that's an ugly sea of nesting.

On Wed, 28 Aug 2024 at 19:01, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On Friday, 23 August 2024 at 17:39:39 UTC, Manu wrote:
> Validations are usually a series of exclusionary checks framed
> as
> `if(fails_validity_check) return;`
> That flow keeps code in a nice linear flow, it doesn't
> introduce any scopes

Aren't returns grouped near the end of function? Then validation
checks would be implemented as forward jumps, which at least
riscv interprets as unlikely by default.