The implementation of `/p` does not follow the documentation

[book]

As noted by @haarg in this comment:

The documentation states that since perl 5.20, the /p flag is ignored and ${^MATCH} is equivalent to $&. This is incorrect. The /p flag is not ignored, and still controls the population of ${^MATCH} etc. The simplest resolution to this is likely to make the behavior match the documentation

As I'm currently working on implementing PPC0014, I've bumped into this issue. And I agree with @haarg's conclusion (fix the implementation).

[book]

Meaning: not only the match variables (${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH}) should always exist and be populated, but they should be aliased to $`, $&, and $'.

[book]

The documentation regarding /p was updated in 6380554 and 60c5257. The previous version could be used as examples for writing the updated docs when /p has become an actual no-op.

[jkeenan]

As noted by @haarg in this comment:

The documentation states that since perl 5.20, the /p flag is ignored and ${^MATCH} is equivalent to $&. This is incorrect. The /p flag is not ignored, and still controls the population of ${^MATCH} etc. The simplest resolution to this is likely to make the behavior match the documentation

As I'm currently working on implementing PPC0014, I've bumped into this issue. And I agree with @haarg's conclusion (fix the implementation).

Can you identify the specific passages in the documentation to which the behavior must conform?

And can you also identify the specific areas of guts code that we will need to modify in a pull request to change the behavior to be conformant?

[book]

Can you identify the specific passages in the documentation to which the behavior must conform?

In perlre, the "Modfiers/Overview" section says:

p

Preserve the string matched such that ${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH} are available for use after matching.

In Perl 5.20 and higher this is ignored. Due to a new copy-on-write mechanism, ${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH} will be available after the match regardless of the modifier.

In perlop, the "Regexp Quote-Like Operators" section says:

p   When matching preserve a copy of the matched string so
    that ${^PREMATCH}, ${^MATCH}, ${^POSTMATCH} will be
    defined (ignored starting in v5.20 as these are always
    defined starting in that release)

In perlreref, the section "OPERATORS" says:

p  Preserve a copy of the matched string -
  ${^PREMATCH}, ${^MATCH}, ${^POSTMATCH} will be defined.

The last one contradicts the previous too two, but properly describes the current implementation:

$ ./perl -Ilib -E '"abc" =~ /b/; say ${^PREMATCH}'



$ ./perl -Ilib -E '"abc" =~ /b/p; say for ${^PREMATCH}, ${^MATCH}, ${^POSTMATCH}'
a
b
c

And can you also identify the specific areas of guts code that we will need to modify in a pull request to change the behavior to be conformant?

I'm still an aspiring core dev, so I have little insight on "specific areas" (and I heard the regexp engine is the stuff of nightmares...); however, I believe grepping for RXf_PMf_KEEPCOPY should point to most of the relevant places.

[jkeenan]

Can you identify the specific passages in the documentation to which the behavior must conform?

In perlre, the "Modfiers/Overview" section says:

p
Preserve the string matched such that ${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH} are available for use after matching.
In Perl 5.20 and higher this is ignored. Due to a new copy-on-write mechanism, ${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH} will be available after the match regardless of the modifier.

In perlop, the "Regexp Quote-Like Operators" section says:

p   When matching preserve a copy of the matched string so
    that ${^PREMATCH}, ${^MATCH}, ${^POSTMATCH} will be
    defined (ignored starting in v5.20 as these are always
    defined starting in that release)

In perlreref, the section "OPERATORS" says:

p  Preserve a copy of the matched string -
  ${^PREMATCH}, ${^MATCH}, ${^POSTMATCH} will be defined.

The last one contradicts the previous too, but properly describes the current implementation:

Here I'm confused. I suspect you meant to type the number 2, as in:
The last one contradicts the previous two, but properly describes the current implementation

But even so ... if 1 of our documentation instances contradicts the other 2, don't we have to reconcile that contradiction in the docs before we can rectify the implementation?

[haarg]

As long as the end result is that all of the docs match and it matches the implementation, I'm not sure it matters what order we update them.