It is. But only for:

{
    my $state_var;
    sub foo { ...; }
}
[download]

But not for:

{
    my $state_var;
    sub foo { ...; }
    sub bar { ...; }
}
[download]

Which is a perfectly valid and common use of closures.

Thus it only deals with half the requirement. And so, (IMO), it is flawed.

While I agree that:

{
    my $state_var;
    sub foo { ...; }
    sub bar { ...; }
}
[download]

is a perfectly valid and common use of closures, I would not want:

sub foo { state $state_var; ...; }
sub bar { state $state_var; ...; }
[download]

to auto-magically assume both (or all at "same" level) declarations of $state_var to be the same variable.

I am pretty sure that state was not designed as a replacement for "traditional" closure constructs, rather just as a short cut for a specific use case.

I would not want: ... to auto-magically assume both (or all at "same" level) declarations of $state_var to be the same variable.

I agree. That would be broken.

But having been bitten by having to convert uses of state back to the traditional form; I simply don't think the "convenience" factor is real. It's just not worth the (my) bother.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!