A named subroutine is created at compile time, putting them into other subs or loops means begging for trouble.

I've never been a big fan of state, there are not many patterns (if any) which can't be implemented with closed over my declarations.

Oh yes, for sure defining one named subroutine within another is almost never what you want. The following is a much clearer way to do things.

use v5.30;
use strict;
use warnings;

{
  my $add = 0;
  sub getter { $add }
  
  sub counter {
    my @nums = (1..500);
    for my $num (@nums) { $add += $num; }
  }
}

counter();
say "getter => ", getter();
[download]

Though, just returning a value from counter() seems better practice:

use v5.30;
use strict;
use warnings;

sub counter {
  my $add = 0;
  my @nums = (1..500);
  for my $num (@nums) { $add += $num; }
  return $add;
}

my $got = counter();
say "got => ", $got;
[download]

I've never been a big fan of state, there are not many patterns (if any) which can't be implemented with closed over my declarations.

The state keyword is mostly just syntactic sugar. The following are essentially the same:

{
  my $foo = 123;
  sub myfunc {
    ...;
  }
}
[download]

sub myfunc {
  state $foo = 123;
  ...;
}
[download]

The latter allows you to eliminate a level of nesting. Also in the case where the value being assigned to $foo is expensive to calculate, it means you won't need to calculate it until myfunc is actually called (which might be never in some cases). If you don't care about undef/false values, you can kind of emulate that using:

{
  my $foo;
  sub myfunc {
    $foo ||= 123;
    ...;
  }
}
[download]

toby döt ink

defining one named subroutine within another is almost never what you want.

Definitely. Mine was more a, "hmm, would this work? Yes? Cool!". My original intent was to add caveats, but those never made it in to the post.

Thank you.