This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Stop defined(aassign) from being an error
authorFather Chrysostomos <sprout@cpan.org>
Thu, 14 Aug 2014 00:59:32 +0000 (17:59 -0700)
committerFather Chrysostomos <sprout@cpan.org>
Thu, 14 Aug 2014 00:59:52 +0000 (17:59 -0700)
commitf4ef132eeaba0ed558de187afbee10205ae09a38
tree921120a11d07295d5ebf48f6b4aac0edc3712ba4
parentbb304765b09371ff7ea548bd37e42f9907dabcde
Stop defined(aassign) from being an error

(See the thread starting at
<20140813010036.15038.qmail@lists-nntp.develooper.com>.)

This commit changed the message 'defined(@...) is deprecated' into
a hard error:

commit e35475dec7197e291306173beba241d4e43bd5b2
Author: Karl Williamson <khw@cpan.org>
Date:   Mon Jun 16 18:56:44 2014 -0600

    Fatalize defined(@) and defined{%)

As I pointed out a couple of years (?) ago, this warning was also
showing up in places that did not involve checking the definedness of
an array; namely, defined(any list assignment):

$ perl -we '$_ = defined(my($a,$b)=3)'
defined(@array) is deprecated at -e line 1.
        (Maybe you should just omit the defined()?)

While checking that a list assignment evaluated in scalar context is
useless, as the result (a number) will always be defined, there is no
reason why this code should be any more invalid than ‘rand() > -1’ or
‘defined(time)’.  But now it has inadvertently become a hard error.

This commit simply removes the error for defined(aassign), under the
possibly false assumption that such a mistake will be rare, so it is
not worth clutting up perl itself with a special case for it.  Whether
that assumption is true remains to be seen.  In any case, in the
absence of any data, smaller is better, is it not?
op.c
t/lib/warnings/op