develooper Front page | perl.perl5.porters | Postings from February 2013

[perl #116943] deprecate @*, %*, &*, ** too

Thread Next
Nicholas Clark
February 26, 2013 13:41
[perl #116943] deprecate @*, %*, &*, ** too
Message ID:
# New Ticket Created by  Nicholas Clark 
# Please include the string:  [perl #116943]
# in the subject line of all future correspondence about this issue. 
# <URL: >

perlvar says:

    C<$*> was a variable that you could use to enable multiline matching.
    After a deprecation cycle, its magic was removed in Perl v5.10.0.
    Using it now triggers a warning: C<$* is no longer supported>.
    You should use the C</s> and C</m> regexp modifiers instead.

This is true. In that currently a warning is issued:

$ ./perl -e '$a = $*'
$* is no longer supported at -e line 1.

However, there's no such warning for other things in that typeglob.

$ ./perl -Ilib -e '@* = ( "a", "b" ); print "\$*[1] is $*[1]\n"'
$*[1] is b
$ ./perl -Ilib -e '%* = ( "a", "b" ); print "\$*{a} is $*{a}\n"'
$*{a} is b
$ ./perl -Ilib -e '** = sub { print "Hello world\n" }; &*'
Hello world

I think that we should deprecate the use of *all* of these.
With the intent of freeing up the parser so that things like


can become meaningful in the near future. (Slurpy arrays and slurpy hashes
would be particularly useful for signatures)

I've tried to use csearch to find instances of use of these constructions on
CPAN, but it's very hard to avoid getting a heck of a lot of output from
unrelated things. As best I could work out (using a more restricted search
term), they aren't used. I think that the biggest user may well be JAPHs and
obfuscations relying on this:

$ ./perl -Ilib -le 'print ******'

Nicholas Clark

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About