${^MATCH} regex special variable(s) and /p regex modifier

AnomalousMonk has asked for the wisdom of the Perl Monks concerning the following question:

I'm confused about the behavior of the special match variables ${^PREMATCH} ${^MATCH} ${^POSTMATCH} (see perlvar) in relation to the /p regex modifier, all available in 5.10+. (Note that these are not, AFAIU, the same as the $PREMATCH $MATCH $POSTMATCH variables (again, perlvar), which are just the use English; equivalents of the $` $& $' variables, the notorious '$& and friends'.)

The documentation leads me to believe that ${^MATCH} et al are only valid after a match that uses the /p regex modifier, but the code below produces the same output with or without the /p modifier. What gives?

>perl -wMstrict -le
"my $s = '----abc123++++';
 $s =~ m{ ([[:alpha:]]+) (\d+) }xms;
 print qq{'${^PREMATCH}' '${^MATCH}' '${^POSTMATCH}' ($1) ($2)};
"
'----' 'abc123' '++++' (abc) (123)
[download]

Comment on ${^MATCH} regex special variable(s) and /p regex modifier Select or Download Code

Replies are listed 'Best First'.
Re: ${^MATCH} regex special variable(s) and /p regex modifier by toolic (Bishop) on Oct 04, 2011 at 01:32 UTC
Here is a quote from perlvar: This is similar to $& ($MATCH ) except that it does not incur the performance penalty associated with that variable, and is only guaranteed to return a defined value when the pattern was compiled or executed with the /p modifier. I think the key word there is "guaranteed". It seems like the variable gets defined even if /p is not used, although it is not explicitly mentioned. To be safe, I would always use /p when you want those variables. If you feel the docs should be modified, submit a patch via perlbug.	[reply]
Re: ${^MATCH} regex special variable(s) and /p regex modifier by JavaFan (Canon) on Oct 04, 2011 at 07:03 UTC
That's because you are using parenthesis. Using parens mays you're paying "the penalty" (for that match) anyway. So, you get ${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH} for "free". Try running your match without parens, and see the difference.	[reply]
Re^2: ${^MATCH} regex special variable(s) and /p regex modifier by lidden (Curate) on Oct 04, 2011 at 10:33 UTC
Try running your match without parens, and see the difference. I tried without parens and saw no difference. I tried with perl 5.14.1 and 5.12.2.	[reply]
Re^3: ${^MATCH} regex special variable(s) and /p regex modifier by JavaFan (Canon) on Oct 04, 2011 at 11:15 UTC
With 5.12.2: `$ perl -wE 'my $s = "foo bar"; $s =~ /(bar)/; say ${^PREMATCH}' foo $ perl -wE 'my $s = "foo bar"; $s =~ /bar/; say ${^PREMATCH}' Use of uninitialized value $^PREMATCH in say at -e line 1. $` [download] Note also the difference in what's going on: $ perl -Mre=debug -wE 'my $s = "foo bar"; $s =~ /bar/;' Compiling REx "bar" Final program: 1: EXACT <bar> (3) 3: END (0) anchored "bar" at 0 (checking anchored isall) minlen 3 Guessing start of match in sv for REx "bar" against "foo bar" Found anchored substr "bar" at offset 4... Starting position does not contradict /^/m... Guessed: match at offset 4 Freeing REx: "bar" $ perl -Mre=debug -wE 'my $s = "foo bar"; $s =~ /(bar)/;' Compiling REx "(bar)" Final program: 1: OPEN1 (3) 3: EXACT <bar> (5) 5: CLOSE1 (7) 7: END (0) anchored "bar" at 0 (checking anchored) minlen 3 Guessing start of match in sv for REx "(bar)" against "foo bar" Found anchored substr "bar" at offset 4... Starting position does not contradict /^/m... Guessed: match at offset 4 Matching REx "(bar)" against "bar" 4 <foo > <bar> \| 1:OPEN1(3) 4 <foo > <bar> \| 3:EXACT <bar>(5) 7 <foo bar> <> \| 5:CLOSE1(7) 7 <foo bar> <> \| 7:END(0) Match successful! Freeing REx: "(bar)" $ [download]	[reply] [d/l] [select]
Re^4: ${^MATCH} regex special variable(s) and /p regex modifier by lidden (Curate) on Oct 04, 2011 at 14:16 UTC
Re: ${^MATCH} regex special variable(s) and /p regex modifier by AnomalousMonk (Archbishop) on Oct 05, 2011 at 06:11 UTC
Following the replies of JavaFan and lidden, I tried matching against the string 'foo 123 bar' in Strawberries 5.10.1 and 5.12.3. I found that without the /p modifier `/(123)/` and `/\d+/` 'correctly' assigned to all the `${^MATCH}` variables and `/123/` did not. (All these regexes assign as expected when the /p modifier is used.) I guess the take-away lesson here is toolic's emphasis on the word 'guaranteed' in the documentation: it really does mean what it says. I'm of two minds about submitting a patch request for the docs. On one hand, the current documentation states simply and clearly what is guaranteed and the conditions of the guarantee. On the other hand, I have a compulsion to warn that without the protection of the /p modifier, there are situations in which the `${^MATCH}` variables may seem to work properly without, in fact, doing so reliably; i.e., one may spend the day ambling very enjoyably through the jungle, then suddenly find oneself standing in a ten foot deep hole with a five foot bamboo stake up a very sensitive place. Must think on this.	[reply] [d/l] [select]