perldeprecation (1) Linux Manual Page
NAME
perldeprecation – list Perl deprecations
DESCRIPTION
The purpose of this document is to document what has been deprecated in Perl, and by which version the deprecated feature will disappear, or, for already removed features, when it was removed.
This document will try to discuss what alternatives for the deprecated features are available.
The deprecated features will be grouped by the version of Perl in which they will be removed.
Perl 5.32
Constants from lexical variables potentially modified elsewhere
You wrote something like
my $var;
$sub = sub () { $var };
but $var is referenced elsewhere and could be modified after the "sub" expression is evaluated. Either it is explicitly modified elsewhere ("$var = 3") or it is passed to a subroutine or to an operator like "printf" or "map", which may or may not modify the variable.
Traditionally, Perl has captured the value of the variable at that point and turned the subroutine into a constant eligible for inlining. In those cases where the variable can be modified elsewhere, this breaks the behavior of closures, in which the subroutine captures the variable itself, rather than its value, so future changes to the variable are reflected in the subroutine’s return value.
If you intended for the subroutine to be eligible for inlining, then make sure the variable is not referenced elsewhere, possibly by copying it:
my $var2 = $var;
$sub = sub () { $var2 };
If you do want this subroutine to be a closure that reflects future changes to the variable that it closes over, add an explicit "return":
my $var;
$sub = sub(){return $var};
This usage has been deprecated, and will no longer be allowed in Perl 5.32.
Use of strings with code points over 0xFF as arguments to "vec"
"vec" views its string argument as a sequence of bits. A string containing a code point over 0xFF is nonsensical. This usage is deprecated in Perl 5.28, and will be removed in Perl 5.32.
Use of code points over 0xFF in string bitwise operators
The string bitwise operators, "&", "|", "^", and "~", treat their operands as strings of bytes. As such, values above 0xFF are nonsensical. Some instances of these have been deprecated since Perl 5.24, and were made fatal in 5.28, but it turns out that in cases where the wide characters did not affect the end result, no deprecation notice was raised, and so remain legal. Now, all occurrences either are fatal or raise a deprecation warning, so that the remaining legal occurrences will be fatal in 5.32.
An example of this is
"" & "
