It has to do with backtracking, because:
1) The problem disappears when `:ratchet` mode is enabled in the top-level
regex:
➜ my regex meh ($t) { . };
➜ say "ab" ~~ /^ :ratchet <meh(1)> $ /;
Nil
2) The problem disappears when the named regex is made a `token`:
➜ my token meh ($t) { . };
➜ say "ab" ~~ /^ <meh(1)> $ /;
Nil
Of course, the regex engine could avoid backtracking entirely in that example,
but maybe it's just not optimized enough to know that.
Here's a different example in which backtracking is actually necessary:
my regex meh ($t) {
{ say "meh start"}
.+?
{ say "meh end"}
}
say "abcde" ~~ /
^
<meh(42)> { say '$<meh> = ', $<meh> }
$
/;
It outputs:
meh start
meh end
$<meh> = ｢abcde｣
Too few positionals passed; expected 2 arguments but got 1
in regex meh at [...]
Note how the error message appears after having reached the end of the regex
for the first time, just before it would have backtracked into `meh` for the
first time.
In comparison, when removing the parameterization of `meh`, the example prints
the following (Note how it backtracked into `meh` four times, like it should):
meh start
meh end
$<meh> = ｢a｣
meh end
$<meh> = ｢ab｣
meh end
$<meh> = ｢abc｣
meh end
$<meh> = ｢abcd｣
meh end
$<meh> = ｢abcde｣
In summary, what *appears* to be happening, is this:
- If a named subrule is called with parameters...
- And it matched...
- But then the regex engine wants to backtrack into it...
- Then it "calls" the subrule again, but fails to pass the parameters again.
