You seem to be carving out an exception for something like this:

use strict;
use warnings;
use 5.012;

use threads;

my $x = 20;

sub do_stuff{ 
    my $thread_id = shift;

    say "In thread $thread_id: ", ++$x;
}

threads->create(\&do_stuff, 1)->join();

say "In thread 'main': $x";


--output:--
In thread 1: 21
In thread 'main': 20
[download]

But even though the thread closes over $x, it cannot change the $x in main. So, it appears to me that the closed over variable is also thread local.

So, it appears to me that the closed over variable is also thread local.

It is visible from two (or more) threads, not just the one where it was declared. Is that "thread-local"?

Modifications to either the declared original or the undeclared, closed-over copy are thread-local; but the name, and its spawn-time value are not.

Like the perennial list versus array debate, it all comes down to managing the expectations of people interpretation of what the term means; rather than the letter of the law with respect to the internal realities.

I prefer to avoid 'instance (mis)understanding' -- like the wide-spread fallacy that Copy-On-Write gives essentially cost-free sharing of read-only data.

If you tell people the truth -- warts'n'all -- and then show them how to avoid the warts; they'll often accept the warts and the need to avoid them, in favour of the pragmatic view of whatever it takes to get the job done.

Conversely, if you try to gloss-over the warts and pretend everything is rosey, they'll curse you the first time they are bitten, and never return.

---

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.