I tried your code on "unthreaded" perl and it prints twice. It seems like this weird "interpolation" ° resolves to "x1" =~ /x1/ which doesn't make much sense as a bug demo.

On a perl interpreter compiled without threads support it prints "doing arg" once; on a threaded perl interpreter it prints twice - see the example run below. The match itself works correctly in both cases: it resolves to /x1/. My example was to show that there are strange side-effects which depend on the particlar perl interpreter you run it under. There are other edge case effects, the details of which I can't recall off the top of my head.

$ perl5420 -v
This is perl 5, version 42, subversion 0 (v5.42.0) built for x86_64-li
+nux
$ perl5420 ~/tmp/p
doing arg
match
match
$ perl5420t -v
This is perl 5, version 42, subversion 0 (v5.42.0) built for x86_64-li
+nux-thread-multi
$ perl5420t ~/tmp/p
doing arg
match
doing arg
match
$
[download]

Dave.

Thanks for the clarification. °

Honestly, when injecting code evaluation into a variable interpolation, I'm not surprised to get inconsistent side effects.

It would be of bigger concern if it also happened with more "official" means like (?{...}) or (??{...})

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

°) how popular are Perl builds without thread support?

The "code injection" was just a quick and dirty demonstration of a side-effect. Its shows that on a threaded build, the expression which defines the pattern is assembled each time, but then thrown away unused apart from the first iteration. Think for example of a tied array. The following:

for my $i (0,1) {
    /abc$tied_array[$i]/;
}
[download]

will, on threaded builds, invoke both $tied_array->FETCH(0) and $tied_array->FETCH(1), but will discard the second value.

Dave.