It implies that the decision was somewhat arbitrary and that it could still work the old way, except someone chose to add another *wart* to perl and create another exception -- that RE's work a certain way in some places, but another way when described by 'qr'.

As for 'x' working -- i'd call this broken. Why not use the example I provided that shows the broken behavior rather than coming up with some different example where you could make it work?

I.e.:

perl -we'use strict;use P;      
my $re = qr{ (?x) (\w+) }; 
my $dat = "Just another cats meow";
my @matches = $dat =~ $re;   
P "#matches=%s, matches=%s", scalar(@matches), \@matches;
exit scalar(@matches);'
#matches=1, matches=["another"]
[download]

the above doesn't work. It doesn't return the 1st match from the text line. As opposed to moving the (?x) to the end of the qr statement:

perl -we'use strict;use P;      
my $re = qr{ (\w+) }x;    
my $dat = "Just another cats meow";
my @matches = $dat =~ $re;   
P "#matches=%s, matches=%s", scalar(@matches), \@matches;
exit scalar(@matches);'
#matches=1, matches=["Just"]
[download]

In the case where I am not using 'g', One would expect the re to match and return the 1st word in the list. With (?x), it doesn't return the 1st word, but returns the 2nd, vs. with 'x' as a suffix, it behaves as expected and only returns the 1st matching word.

Then you claim the status quo makes sense, when the perl mastery book clearly shows that 'qr' can stand as an RE by itself without 'm' or 's' -- AND it is more efficient when it is used that way. Except it has been crippled by differences in how 'RE's work in 'qr' vs. ones that are "requoted", re-interpolated, and re-compiled in 'm' & 's'. Why is there a difference when 'qr' can be used "standalone"? "qr" wasn't meant to replace 's', but it was meant to replace or be equivalent to 'm'.

Did you see the 3 ways Mastering perl uses 'qr'. The first way, where it is interpolated, seems to have little benefit over using q(string). then interpolating the string into the m{} statement. But if you can use 'qr' w/o the m{}, you only do the RE-compile once when you use 'qr' -- which can be used to match things directly in "=~" statements -- just like m{} statements are used.

So again, I ask 'why' the artificial constraint when, from the deprecation warning, it seems apparent, that it used to work.

I’m guessing you’re running a fairly old version of Perl? On 5.20.2, I get:

Unknown regexp modifier "/g" at 1645_SoPW.pl line 18, near "= "
[download]

— which is clear. But on 5.12.3, I get:

Bareword found where operator expected at 1645_SoPW.pl line 18, near "
+qr{ (\w+) }gx"
syntax error at 1645_SoPW.pl line 18, near "qr{ (\w+) }gx"
[download]

— which isn’t. In any case, the “deprecated” message you’re seeing is related only indirectly to the presence of a /g modifier on a qr// term. The Perl compiler is simply confused as to what the syntax is supposed to mean, and its (incorrect) guess leads it to find a construct which you never intended and which happens to be deprecated.

Actually, the qr// syntax was introduced in Perl 5.005,¹ which was released in 1998. The first edition of the Camel Book to document qr// was the third edition, published in July, 2000 (4 months after the release of Perl 5.6). The section “Pattern-Matching Operators” in Chapter 5 draws a distinction between those modifiers which apply to a regex (are are therefore applicable to qr//) and those which apply to an operator (and are therefore applicable only to m// and s///).² The /g modifier falls in the second category. So, AFAICT, putting a /g modifier on a qr// term is not “deprecated,” as it was never allowed in the first place.

¹Update (May 30, 2016): See perl5005delta#New qr// operator.
²Compare the tables on pages 147 and 150.

Hope that helps,

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

You're switching on ?x too late in the regular expression:

#!perl -w
use strict;
use Data::Dumper;
my $dat = "Just another cats meow";

sub print_matches {
    my( $re ) = @_;
    my @matches = $dat =~ /$re/;   
    print "Using $re\n";
    print "#matches=%s, matches=%s", scalar(@matches), Dumper \@matche
+s;
};

print_matches( qr{ (?x) (\w+) } ); 
print_matches( qr{(?x) (\w+) } ); 

__END__
Using (?^: (?x) (\w+) )
#matches=%s, matches=%s1$VAR1 = [
          'another'
        ];
Using (?^:(?x) (\w+) )
#matches=%s, matches=%s1$VAR1 = [
          'Just'
        ];
[download]

The first whitespace is not governed by ?x.

Bingo on that one... Too many spaces before telling it to ignore spaces...erk!

how now brown cow

did you try splain?

Having no space between pattern and following word is deprecated at -e
+ line 2.
Having no space between pattern and following word is deprecated at -e
+ line 2 (#1)
    (D syntax)

    You had a word that isn't a regex modifier immediately following
    a pattern without an intervening space.  If you are trying to use
    the /le flags on a substitution, use /el instead.  Otherwise, add
    white space between the pattern and following word to eliminate
    the warning.  As an example of the latter, the two constructs:

     $a =~ m/$foo/sand $bar
     $a =~ m/$foo/s and $bar

    both currently mean the same thing, but it is planned to disallow
    the first form in Perl 5.18.  And,

     $a =~ m/$foo/and $bar

    will be disallowed too.
[download]

Do you get it?

That is in addition to Bareword found where operator expected

None of that means qr//g ever worked or was meant to work, the g was always ignored by qr