You In Here :
/
/
proc /
self /
root /
usr /
share /
perl5 /
pod /=encoding utf8
=head1 NAME
perl5140delta - what is new for perl v5.14.0
=head1 DESCRIPTION
This document describes differences between the 5.12.0 release and
the 5.14.0 release.
If you are upgrading from an earlier release such as 5.10.0, first read
L
, which describes differences between 5.10.0 and
5.12.0.
Some of the bug fixes in this release have been backported to subsequent
releases of 5.12.x. Those are indicated with the 5.12.x version in
parentheses.
=head1 Notice
As described in L, the release of Perl 5.14.0 marks the
official end of support for Perl 5.10. Users of Perl 5.10 or earlier
should consider upgrading to a more recent release of Perl.
=head1 Core Enhancements
=head2 Unicode
=head3 Unicode Version 6.0 is now supported (mostly)
Perl comes with the Unicode 6.0 data base updated with
L,
with one exception noted below.
See L for the character at U+1F514,
which is a symbol that looks like a bell, and is used in Japanese cell
phones. This conflicts with the long-standing Perl usage of having
C mean the ASCII C character, U+0007. In Perl 5.14,
C<\N{BELL}> continues to mean U+0007, but its use generates a
deprecation warning message unless such warnings are turned off. The
new name for U+0007 in Perl is C, which corresponds nicely
with the existing shorthand sequence for it, C<"\a">. C<\N{BEL}>
means U+0007, with no warning given. The character at U+1F514 has no
name in 5.14, but can be referred to by C<\N{U+1F514}>.
In Perl 5.16, C<\N{BELL}> will refer to U+1F514; all code
that uses C<\N{BELL}> should be converted to use C<\N{ALERT}>,
C<\N{BEL}>, or C<"\a"> before upgrading.
=head3 Full functionality for C
This release provides full functionality for C. Under its scope, all string operations executed and
regular expressions compiled (even if executed outside its scope) have
Unicode semantics. See L.
However, see L,
below.
This feature avoids most forms of the "Unicode Bug" (see
L for details). If there is any
possibility that your code will process Unicode strings, you are
I encouraged to use this subpragma to avoid nasty surprises.
=head3 C<\N{I}> and C enhancements
=over
=item *
C<\N{I}> and C now know about the abbreviated
character names listed by Unicode, such as NBSP, SHY, LRO, ZWJ, etc.; all
customary abbreviations for the C0 and C1 control characters (such as
ACK, BEL, CAN, etc.); and a few new variants of some C1 full names that
are in common usage.
=item *
Unicode has several I, in which particular sequences
of code points are given names. C<\N{I}> now recognizes these.
=item *
C<\N{I}>, C, and C
now know about every character in Unicode. In earlier releases of
Perl, they didn't know about the Hangul syllables nor several
CJK (Chinese/Japanese/Korean) characters.
=item *
It is now possible to override Perl's abbreviations with your own custom aliases.
=item *
You can now create a custom alias of the ordinal of a
character, known by C<\N{I}>, C, and
C. Previously, aliases had to be to official
Unicode character names. This made it impossible to create an alias for
unnamed code points, such as those reserved for private
use.
=item *
The new function charnames::string_vianame() is a run-time version
of C<\N{I}}>, returning the string of characters whose Unicode
name is its parameter. It can handle Unicode named character
sequences, whereas the pre-existing charnames::vianame() cannot,
as the latter returns a single code point.
=back
See L for details on all these changes.
=head3 New warnings categories for problematic (non-)Unicode code points.
Three new warnings subcategories of "utf8" have been added. These
allow you to turn off some "utf8" warnings, while allowing
other warnings to remain on. The three categories are:
C when UTF-16 surrogates are encountered;
C when Unicode non-character code points are encountered;
and C when code points above the legal Unicode
maximum of 0x10FFFF are encountered.
=head3 Any unsigned value can be encoded as a character
With this release, Perl is adopting a model that any unsigned value
can be treated as a code point and encoded internally (as utf8)
without warnings, not just the code points that are legal in Unicode.
However, unless utf8 or the corresponding sub-category (see previous
item) of lexical warnings have been explicitly turned off, outputting
or executing a Unicode-defined operation such as upper-casing
on such a code point generates a warning. Attempting to input these
using strict rules (such as with the C<:encoding(UTF-8)> layer)
will continue to fail. Prior to this release, handling was
inconsistent and in places, incorrect.
Unicode non-characters, some of which previously were erroneously
considered illegal in places by Perl, contrary to the Unicode Standard,
are now always legal internally. Inputting or outputting them
works the same as with the non-legal Unicode code points, because the Unicode
Standard says they are (only) illegal for "open interchange".
=head3 Unicode database files not installed
The Unicode database files are no longer installed with Perl. This
doesn't affect any functionality in Perl and saves significant disk
space. If you need these files, you can download them from
L would previously be stringified as
C<(?i-xsm:hlagh)>, but now it's stringified as C<(?^i:hlagh)>.
The main purpose of this change is to allow tests that rely on the
stringification I to have to change whenever new modifiers are added.
See L.
This change is likely to break code that compares stringified regular
expressions with fixed strings containing C.
=head3 C, C, C, and C modifiers
Four new regular expression modifiers have been added. These are mutually
exclusive: one only can be turned on at a time.
=over
=item *
The C modifier says to compile the regular expression as if it were
in the scope of C, even if it is not.
=item *
The C modifier says to compile the regular expression as if it were
in the scope of a C pragma.
=item *
The C (default) modifier is used to override any C and
C pragmas in effect at the time
of compiling the regular expression.
=item *
The C regular expression modifier restricts C<\s>, C<\d> and C<\w> and
the POSIX (C<[[:posix:]]>) character classes to the ASCII range. Their
complements and C<\b> and C<\B> are correspondingly
affected. Otherwise, C behaves like the C modifier, in that
case-insensitive matching uses Unicode semantics.
If the C modifier is repeated, then additionally in case-insensitive
matching, no ASCII character can match a non-ASCII character.
For example,
"k" =~ /\N{KELVIN SIGN}/ai
"\xDF" =~ /ss/ai
match but
"k" =~ /\N{KELVIN SIGN}/aai
"\xDF" =~ /ss/aai
do not match.
=back
See L for more detail.
=head3 Non-destructive substitution
The substitution (C. See L for more examples.
=head3 Re-entrant regular expression engine
It is now safe to use regular expressions within C<(?{...})> and
C<(??{...})> code blocks inside regular expressions.
These blocks are still experimental, however, and still have problems with
lexical (C) variables and abnormal exiting.
=head3 C
The C pragma now has the ability to turn on regular expression flags
till the end of the lexical scope:
use re "/x";
"foo" =~ / (.+) /; # /x implied
See L for details.
=head3 \o{...} for octals
There is a new octal escape sequence, C<"\o">, in doublequote-like
contexts. This construct allows large octal ordinals beyond the
current max of 0777 to be represented. It also allows you to specify a
character in octal which can safely be concatenated with other regex
snippets and which won't be confused with being a backreference to
a regex capture group. See L.
=head3 Add C<\p{Titlecase}> as a synonym for C<\p{Title}>
This synonym is added for symmetry with the Unicode property names
C<\p{Uppercase}> and C<\p{Lowercase}>.
=head3 Regular expression debugging output improvement
Regular expression debugging output (turned on by C) now
uses hexadecimal when escaping non-ASCII characters, instead of octal.
=head3 Return value of C
Custom regular expression engines can now determine the return value of
C on an entry of C<%+> or C<%->.
=head2 Syntactical Enhancements
=head3 Array and hash container functions accept references
B This feature is considered experimental, as the exact behaviour
may change in a future version of Perl.
All builtin functions that operate directly on array or hash
containers now also accept unblessed hard references to arrays
or hashes:
|----------------------------+---------------------------|
| Traditional syntax | Terse syntax |
|----------------------------+---------------------------|
| push @$arrayref, @stuff | push $arrayref, @stuff |
| unshift @$arrayref, @stuff | unshift $arrayref, @stuff |
| pop @$arrayref | pop $arrayref |
| shift @$arrayref | shift $arrayref |
| splice @$arrayref, 0, 2 | splice $arrayref, 0, 2 |
| keys %$hashref | keys $hashref |
| keys @$arrayref | keys $arrayref |
| values %$hashref | values $hashref |
| values @$arrayref | values $arrayref |
| ($k,$v) = each %$hashref | ($k,$v) = each $hashref |
| ($k,$v) = each @$arrayref | ($k,$v) = each $arrayref |
|----------------------------+---------------------------|
This allows these builtin functions to act on long dereferencing chains
or on the return value of subroutines without needing to wrap them in
C<@{}> or C<%{}>:
push @{$obj->tags}, $new_tag; # old way
push $obj->tags, $new_tag; # new way
for ( keys %{$hoh->{genres}{artists}} ) {...} # old way
for ( keys $hoh->{genres}{artists} ) {...} # new way
=head3 Single term prototype
The C<+> prototype is a special alternative to C<$> that acts like
C<\[@%]> when given a literal array or hash variable, but will otherwise
force scalar context on the argument. See L.
=head3 C block syntax
A package declaration can now contain a code block, in which case the
declaration is in scope inside that block only. So C
is precisely equivalent to C<{ package Foo; ... }>. It also works with
a version number in the declaration, as in C,
which is its most attractive feature. See L.
=head3 Statement labels can appear in more places
Statement labels can now occur before any type of statement or declaration,
such as C.
=head3 Stacked labels
Multiple statement labels can now appear before a single statement.
=head3 Uppercase X/B allowed in hexadecimal/binary literals
Literals may now use either upper case C<0X...> or C<0B...> prefixes,
in addition to the already supported C<0x...> and C<0b...>
syntax [perl #76296].
C, Ruby, Python, and PHP already support this syntax, and it makes
Perl more internally consistent: a round-trip with C now returns C<16>, just like C.
=head3 Overridable tie functions
C, C and C can now be overridden [perl #75902].
=head2 Exception Handling
To make them more reliable and consistent, several changes have been made
to how C, C, and C<$@> behave.
=over
=item *
When an exception is thrown inside an C, the exception is no
longer at risk of being clobbered by destructor code running during unwinding.
Previously, the exception was written into C<$@>
early in the throwing process, and would be overwritten if C was
used internally in the destructor for an object that had to be freed
while exiting from the outer C. Now the exception is written
into C<$@> last thing before exiting the outer C, so the code
running immediately thereafter can rely on the value in C<$@> correctly
corresponding to that C. (C<$@> is still also set before exiting the
C, for the sake of destructors that rely on this.)
Likewise, a C inside an C no longer clobbers any
exception thrown in its scope. Previously, the restoration of C<$@> upon
unwinding would overwrite any exception being thrown. Now the exception
gets to the C anyway. So C is safe before a C.
Exceptions thrown from object destructors no longer modify the C<$@>
of the surrounding context. (If the surrounding context was exception
unwinding, this used to be another way to clobber the exception being
thrown.) Previously such an exception was
sometimes emitted as a warning, and then either was
string-appended to the surrounding C<$@> or completely replaced the
surrounding C<$@>, depending on whether that exception and the surrounding
C<$@> were strings or objects. Now, an exception in this situation is
always emitted as a warning, leaving the surrounding C<$@> untouched.
In addition to object destructors, this also affects any function call
run by XS code using the C flag.
=item *
Warnings for C can now be objects in the same way as exceptions
for C. If an object-based warning gets the default handling
of writing to standard error, it is stringified as before with the
filename and line number appended. But a C<$SIG{__WARN__}> handler now
receives an object-based warning as an object, where previously it
was passed the result of stringifying the object.
=back
=head2 Other Enhancements
=head3 Assignment to C<$0> sets the legacy process name with prctl() on Linux
On Linux the legacy process name is now set with L, in
addition to altering the POSIX name via C, as Perl has done
since version 4.000. Now system utilities that read the legacy process
name such as I, I, and I recognize the name you set when
assigning to C<$0>. The string you supply is truncated at 16 bytes;
this limitation is imposed by Linux.
=head3 srand() now returns the seed
This allows programs that need to have repeatable results not to have to come
up with their own seed-generating mechanism. Instead, they can use srand()
and stash the return value for future use. One example is a test program with
too many combinations to test comprehensively in the time available for
each run. It can test a random subset each time and, should there be a failure,
log the seed used for that run so this can later be used to produce the same results.
=head3 printf-like functions understand post-1980 size modifiers
Perl's printf and sprintf operators, and Perl's internal printf replacement
function, now understand the C90 size modifiers "hh" (C), "z"
(C), and "t" (C). Also, when compiled with a C99
compiler, Perl now understands the size modifier "j" (C)
(but this is not portable).
So, for example, on any modern machine, C returns "1".
=head3 New global variable C<${^GLOBAL_PHASE}>
A new global variable, C<${^GLOBAL_PHASE}>, has been added to allow
introspection of the current phase of the Perl interpreter. It's explained in
detail in L and in
L.
=head3 C<-d:-foo> calls C
The syntax B<-d:foo> was extended in 5.6.1 to make B<-d:foo=bar>
equivalent to B<-MDevel::foo=bar>, which expands
internally to C.
Perl now allows prefixing the module name with B<->, with the same
semantics as B<-M>; that is:
=over 4
=item C<-d:-foo>
Equivalent to B<-M-Devel::foo>: expands to
C and calls C<< Devel::foo->unimport() >>
if that method exists.
=item C<-d:-foo=bar>
Equivalent to B<-M-Devel::foo=bar>: expands to C,
and calls C<< Devel::foo->unimport("bar") >> if that method exists.
=back
This is particularly useful for suppressing the default actions of a
C module's C method whilst still loading it for debugging.
=head3 Filehandle method calls load L on demand
When a method call on a filehandle would die because the method cannot
be resolved and L has not been loaded, Perl now loads L
via C and attempts method resolution again:
open my $fh, ">", $file;
$fh->binmode(":raw"); # loads IO::File and succeeds
This also works for globs like C, C, and C:
STDOUT->autoflush(1);
Because this on-demand load happens only if method resolution fails, the
legacy approach of manually loading an L parent class for partial
method support still works as expected:
use IO::Handle;
open my $fh, ">", $file;
$fh->autoflush(1); # IO::File not loaded
=head3 Improved IPv6 support
The C module provides new affordances for IPv6,
including implementations of the C and
C functions, along with related constants and a
handful of new functions. See L.
=head3 DTrace probes now include package name
The C probes now include an additional argument, C, which contains
the package the subroutine being entered or left was compiled in.
For example, using the following DTrace script:
perl$target:::sub-entry
{
printf("%s::%s\n", copyinstr(arg0), copyinstr(arg3));
}
and then running:
$ perl -e 'sub test { }; test'
C will print:
main::test
=head2 New C APIs
See L.
=head1 Security
=head2 User-defined regular expression properties
L documented that you can
create custom properties by defining subroutines whose names begin with
"In" or "Is". However, Perl did not actually enforce that naming
restriction, so C<\p{foo::bar}> could call foo::bar() if it existed. The documented
convention is now enforced.
Also, Perl no longer allows tainted regular expressions to invoke a
user-defined property. It simply dies instead [perl #82616].
=head1 Incompatible Changes
Perl 5.14.0 is not binary-compatible with any previous stable release.
In addition to the sections that follow, see L.
=head2 Regular Expressions and String Escapes
=head3 Inverted bracketed character classes and multi-character folds
Some characters match a sequence of two or three characters in C
regular expression matching under Unicode rules. One example is
C which matches the sequence C.
'ss' =~ /\A[\N{LATIN SMALL LETTER SHARP S}]\z/i # Matches
This, however, can lead to very counter-intuitive results, especially
when inverted. Because of this, Perl 5.14 does not use multi-character C
matching in inverted character classes.
'ss' =~ /\A[^\N{LATIN SMALL LETTER SHARP S}]+\z/i # ???
This should match any sequences of characters that aren't the C
nor what C matches under C. C<"s"> isn't C, but
Unicode says that C<"ss"> is what C matches under C. So
which one "wins"? Do you fail the match because the string has C or
accept it because it has an C followed by another C?
Earlier releases of Perl did allow this multi-character matching,
but due to bugs, it mostly did not work.
=head3 \400-\777
In certain circumstances, C<\400>-C<\777> in regexes have behaved
differently than they behave in all other doublequote-like contexts.
Since 5.10.1, Perl has issued a deprecation warning when this happens.
Now, these literals behave the same in all doublequote-like contexts,
namely to be equivalent to C<\x{100}>-C<\x{1FF}>, with no deprecation
warning.
Use of C<\400>-C<\777> in the command-line option B<-0> retain their
conventional meaning. They slurp whole input files; previously, this
was documented only for B<-0777>.
Because of various ambiguities, you should use the new
C<\o{...}> construct to represent characters in octal instead.
=head3 Most C<\p{}> properties are now immune to case-insensitive matching
For most Unicode properties, it doesn't make sense to have them match
differently under C case-insensitive matching. Doing so can lead
to unexpected results and potential security holes. For example
m/\p{ASCII_Hex_Digit}+/i
could previously match non-ASCII characters because of the Unicode
matching rules (although there were several bugs with this). Now
matching under C gives the same results as non-C matching except
for those few properties where people have come to expect differences,
namely the ones where casing is an integral part of their meaning, such
as C and C, both of which match
the same code points as matched by C.
Details are in L.
User-defined property handlers that need to match differently under C
must be changed to read the new boolean parameter passed to them, which
is non-zero if case-insensitive matching is in effect and 0 otherwise.
See L.
=head3 \p{} implies Unicode semantics
Specifying a Unicode property in the pattern indicates
that the pattern is meant for matching according to Unicode rules, the way
C<\N{I}> does.
=head3 Regular expressions retain their localeness when interpolated
Regular expressions compiled under C now retain this when
interpolated into a new regular expression compiled outside a
C, and vice-versa.
Previously, one regular expression interpolated into another inherited
the localeness of the surrounding regex, losing whatever state it
originally had. This is considered a bug fix, but may trip up code that
has come to rely on the incorrect behaviour.
=head3 Stringification of regexes has changed
Default regular expression modifiers are now notated using
C<(?^...)>. Code relying on the old stringification will fail.
This is so that when new modifiers are added, such code won't
have to keep changing each time this happens, because the stringification
will automatically incorporate the new modifiers.
Code that needs to work properly with both old- and new-style regexes
can avoid the whole issue by using (for perls since 5.9.5; see L):
use re qw(regexp_pattern);
my ($pat, $mods) = regexp_pattern($re_ref);
If the actual stringification is important or older Perls need to be
supported, you can use something like the following:
# Accept both old and new-style stringification
my $modifiers = (qr/foobar/ =~ /\Q(?^/) ? "^" : "-xism";
And then use C<$modifiers> instead of C<-xism>.
=head3 Run-time code blocks in regular expressions inherit pragmata
Code blocks in regular expressions (C<(?{...})> and C<(??{...})>) previously
did not inherit pragmata (strict, warnings, etc.) if the regular expression
was compiled at run time as happens in cases like these two:
use re "eval";
$foo =~ $bar; # when $bar contains (?{...})
$foo =~ /$bar(?{ $finished = 1 })/;
This bug has now been fixed, but code that relied on the buggy behaviour
may need to be fixed to account for the correct behaviour.
=head2 Stashes and Package Variables
=head3 Localised tied hashes and arrays are no longed tied
In the following:
tie @a, ...;
{
local @a;
# here, @a is a now a new, untied array
}
# here, @a refers again to the old, tied array
Earlier versions of Perl incorrectly tied the new local array. This has
now been fixed. This fix could however potentially cause a change in
behaviour of some code.
=head3 Stashes are now always defined
C now always returns true, even when no symbols have yet been
defined in that package.
This is a side-effect of removing a special-case kludge in the tokeniser,
added for 5.10.0, to hide side-effects of changes to the internal storage of
hashes. The fix drastically reduces hashes' memory overhead.
Calling defined on a stash has been deprecated since 5.6.0, warned on
lexicals since 5.6.0, and warned for stashes and other package
variables since 5.12.0. C has always exposed an
implementation detail: emptying a hash by deleting all entries from it does
not make C false. Hence C is not valid code to
determine whether an arbitrary hash is empty. Instead, use the behaviour
of an empty C<%hash> always returning false in scalar context.
=head3 Clearing stashes
Stash list assignment C<%foo:: = ()> used to make the stash temporarily
anonymous while it was being emptied. Consequently, any of its
subroutines referenced elsewhere would become anonymous, showing up as
"(unknown)" in C. They now retain their package names such that
C returns the original sub name if there is still a reference
to its typeglob and "foo::__ANON__" otherwise [perl #79208].
=head3 Dereferencing typeglobs
If you assign a typeglob to a scalar variable:
$glob = *foo;
the glob that is copied to C<$glob> is marked with a special flag
indicating that the glob is just a copy. This allows subsequent
assignments to C<$glob> to overwrite the glob. The original glob,
however, is immutable.
Some Perl operators did not distinguish between these two types of globs.
This would result in strange behaviour in edge cases: C
would not untie the scalar if the last thing assigned to it was a glob
(because it treated it as C, which unties a handle).
Assignment to a glob slot (such as C<*$glob = \@some_array>) would simply
assign C<\@some_array> to C<$glob>.
To fix this, the C<*{}> operator (including its C<*foo> and C<*$foo> forms)
has been modified to make a new immutable glob if its operand is a glob
copy. This allows operators that make a distinction between globs and
scalars to be modified to treat only immutable globs as globs. (C,
C and C have been left as they are for compatibility's sake,
but will warn. See L.)
This causes an incompatible change in code that assigns a glob to the
return value of C<*{}> when that operator was passed a glob copy. Take the
following code, for instance:
$glob = *foo;
*$glob = *bar;
The C<*$glob> on the second line returns a new immutable glob. That new
glob is made an alias to C<*bar>. Then it is discarded. So the second
assignment has no effect.
See L for
more detail.
=head3 Magic variables outside the main package
In previous versions of Perl, magic variables like C<$!>, C<%SIG>, etc. would
"leak" into other packages. So C<%foo::SIG> could be used to access signals,
C<${"foo::!"}> (with strict mode off) to access C's C, etc.
This was a bug, or an "unintentional" feature, which caused various ill effects,
such as signal handlers being wiped when modules were loaded, etc.
This has been fixed (or the feature has been removed, depending on how you see
it).
=head3 local($_) strips all magic from $_
local() on scalar variables gives them a new value but keeps all
their magic intact. This has proven problematic for the default
scalar variable $_, where L recommends that any subroutine
that assigns to $_ should first localize it. This would throw an
exception if $_ is aliased to a read-only variable, and could in general have
various unintentional side-effects.
Therefore, as an exception to the general rule, local($_) will not
only assign a new value to $_, but also remove all existing magic from
it as well.
=head3 Parsing of package and variable names
Parsing the names of packages and package variables has changed:
multiple adjacent pairs of colons, as in C, are now all
treated as package separators.
Regardless of this change, the exact parsing of package separators has
never been guaranteed and is subject to change in future Perl versions.
=head2 Changes to Syntax or to Perl Operators
=head3 C return values
C blocks now return the last evaluated
expression, or an empty list if the block was exited by C. Thus you
can now write:
my $type = do {
given ($num) {
break when undef;
"integer" when /^[+-]?[0-9]+$/;
"float" when /^[+-]?[0-9]+(?:\.[0-9]+)?$/;
"unknown";
}
};
See L for details.
=head3 Change in parsing of certain prototypes
Functions declared with the following prototypes now behave correctly as unary
functions:
*
\$ \% \@ \* \&
\[...]
;$ ;*
;\$ ;\% etc.
;\[...]
Due to this bug fix [perl #75904], functions
using the C<(*)>, C<(;$)> and C<(;*)> prototypes
are parsed with higher precedence than before. So
in the following example:
sub foo(;$);
foo $a < $b;
the second line is now parsed correctly as C<< foo($a) < $b >>, rather than
C<< foo($a < $b) >>. This happens when one of these operators is used in
an unparenthesised argument:
< > <= >= lt gt le ge
== != <=> eq ne cmp ~~
&
| ^
&&
|| //
.. ...
?:
= += -= *= etc.
, =>
=head3 Smart-matching against array slices
Previously, the following code resulted in a successful match:
my @a = qw(a y0 z);
my @b = qw(a x0 z);
@a[0 .. $#b] ~~ @b;
This odd behaviour has now been fixed [perl #77468].
=head3 Negation treats strings differently from before
The unary negation operator, C<->, now treats strings that look like numbers
as numbers [perl #57706].
=head3 Negative zero
Negative zero (-0.0), when converted to a string, now becomes "0" on all
platforms. It used to become "-0" on some, but "0" on others.
If you still need to determine whether a zero is negative, use
C module on CPAN.
=head3 C<:=> is now a syntax error
Previously C was exactly equivalent to C,
with the C<:> being treated as the start of an attribute list, ending before
the C<=>. The use of C<:=> to mean C<: => was deprecated in 5.12.0, and is
now a syntax error. This allows future use of C<:=> as a new token.
Outside the core's tests for it, we find no Perl 5 code on CPAN
using this construction, so we believe that this change will have
little impact on real-world codebases.
If it is absolutely necessary to have empty attribute lists (for example,
because of a code generator), simply avoid the error by adding a space before
the C<=>.
=head3 Change in the parsing of identifiers
Characters outside the Unicode "XIDStart" set are no longer allowed at the
beginning of an identifier. This means that certain accents and marks
that normally follow an alphabetic character may no longer be the first
character of an identifier.
=head2 Threads and Processes
=head3 Directory handles not copied to threads
On systems other than Windows that do not have
a C function, newly-created threads no
longer inherit directory handles from their parent threads. Such programs
would usually have crashed anyway [perl #75154].
=head3 C on shared pipes
To avoid deadlocks, the C function no longer waits for the
child process to exit if the underlying file descriptor is still
in use by another thread. It returns true in such cases.
=head3 fork() emulation will not wait for signalled children
On Windows parent processes would not terminate until all forked
children had terminated first. However, C is
inherently unstable on pseudo-processes, and C
might not get delivered if the child is blocked in a system call.
To avoid the deadlock and still provide a safe mechanism to terminate
the hosting process, Perl now no longer waits for children that
have been sent a SIGTERM signal. It is up to the parent process to
waitpid() for these children if child-cleanup processing must be
allowed to finish. However, it is also then the responsibility of the
parent to avoid the deadlock by making sure the child process
can't be blocked on I/O.
See L for more information about the fork() emulation on
Windows.
=head2 Configuration
=head3 Naming fixes in Policy_sh.SH may invalidate Policy.sh
Several long-standing typos and naming confusions in F have
been fixed, standardizing on the variable names used in F.
This will change the behaviour of F if you happen to have been
accidentally relying on its incorrect behaviour.
=head3 Perl source code is read in text mode on Windows
Perl scripts used to be read in binary mode on Windows for the benefit
of the L module (which is no longer part of core Perl). This
had the side-effect of breaking various operations on the C filehandle,
including seek()/tell(), and even simply reading from C after filehandles
have been flushed by a call to system(), backticks, fork() etc.
The default build options for Windows have been changed to read Perl source
code on Windows in text mode now. L will (hopefully) be updated on
CPAN to automatically handle this situation [perl #28106].
=head1 Deprecations
See also L.
=head2 Omitting a space between a regular expression and subsequent word
Omitting the space between a regular expression operator or
its modifiers and the following word is deprecated. For
example, C<< m/foo/sand $bar >> is for now still parsed
as C<< m/foo/s and $bar >>, but will now issue a warning.
=head2 C<\cI>
The backslash-c construct was designed as a way of specifying
non-printable characters, but there were no restrictions (on ASCII
platforms) on what the character following the C could be. Now,
a deprecation warning is raised if that character isn't an ASCII character.
Also, a deprecation warning is raised for C<"\c{"> (which is the same
as simply saying C<";">).
=head2 C<"\b{"> and C<"\B{">
In regular expressions, a literal C<"{"> immediately following a C<"\b">
(not in a bracketed character class) or a C<"\B{"> is now deprecated
to allow for its future use by Perl itself.
=head2 Perl 4-era .pl libraries
Perl bundles a handful of library files that predate Perl 5.
This bundling is now deprecated for most of these files, which are now
available from CPAN. The affected files now warn when run, if they were
installed as part of the core.
This is a mandatory warning, not obeying B<-X> or lexical warning bits.
The warning is modelled on that supplied by F for
deprecated-in-core F<.pm> libraries. It points to the specific CPAN
distribution that contains the F<.pl> libraries. The CPAN versions, of
course, do not generate the warning.
=head2 List assignment to C<$[>
Assignment to C<$[> was deprecated and started to give warnings in
Perl version 5.12.0. This version of Perl (5.14) now also emits a warning
when assigning to C<$[> in list context. This fixes an oversight in 5.12.0.
=head2 Use of qw(...) as parentheses
Historically the parser fooled itself into thinking that C literals
were always enclosed in parentheses, and as a result you could sometimes omit
parentheses around them:
for $x qw(a b c) { ... }
The parser no longer lies to itself in this way. Wrap the list literal in
parentheses like this:
for $x (qw(a b c)) { ... }
This is being deprecated because the parentheses in C
are not part of expression syntax. They are part of the statement
syntax, with the C statement wanting literal parentheses.
The synthetic parentheses that a C expression acquired were only
intended to be treated as part of expression syntax.
Note that this does not change the behaviour of cases like:
use POSIX qw(setlocale localeconv);
our @EXPORT = qw(foo bar baz);
where parentheses were never required around the expression.
=head2 C<\N{BELL}>
This is because Unicode is using that name for a different character.
See L for more
explanation.
=head2 C
C (without the initial C) has been deprecated and now produces
a warning. This is to allow future use of C in new operators.
The match-once functionality is still available as C.
=head2 Tie functions on scalars holding typeglobs
Calling a tie function (C, C, C) with a scalar argument
acts on a filehandle if the scalar happens to hold a typeglob.
This is a long-standing bug that will be removed in Perl 5.16, as
there is currently no way to tie the scalar itself when it holds
a typeglob, and no way to untie a scalar that has had a typeglob
assigned to it.
Now there is a deprecation warning whenever a tie
function is used on a handle without an explicit C<*>.
=head2 User-defined case-mapping
This feature is being deprecated due to its many issues, as documented in
L.
This feature will be removed in Perl 5.16. Instead use the CPAN module
L, which provides improved functionality.
=head2 Deprecated modules
The following module will be removed from the core distribution in a
future release, and should be installed from CPAN instead. Distributions
on CPAN that require this should add it to their prerequisites. The
core version of these module now issues a deprecation warning.
If you ship a packaged version of Perl, either alone or as part of a
larger system, then you should carefully consider the repercussions of
core module deprecations. You may want to consider shipping your default
build of Perl with a package for the deprecated module that
installs into C or C Perl library directories. This will
inhibit the deprecation warnings.
Alternatively, you may want to consider patching F
to provide deprecation warnings specific to your packaging system
or distribution of Perl, consistent with how your packaging system
or distribution manages a staged transition from a release where the
installation of a single package provides the given functionality, to
a later release where the system administrator needs to know to install
multiple packages to get that same functionality.
You can silence these deprecation warnings by installing the module
in question from CPAN. To install the latest version of it by role
rather than by name, just install C.
=over
=item L
We strongly recommend that you install and use L instead
of L, as L offers significantly
improved profiling and reporting.
=back
=head1 Performance Enhancements
=head2 "Safe signals" optimisation
Signal dispatch has been moved from the runloop into control ops.
This should give a few percent speed increase, and eliminates nearly
all the speed penalty caused by the introduction of "safe signals"
in 5.8.0. Signals should still be dispatched within the same
statement as they were previously. If this does I happen, or
if you find it possible to create uninterruptible loops, this is a
bug, and reports are encouraged of how to recreate such issues.
=head2 Optimisation of shift() and pop() calls without arguments
Two fewer OPs are used for shift() and pop() calls with no argument (with
implicit C<@_>). This change makes shift() 5% faster than C
on non-threaded perls, and 25% faster on threaded ones.
=head2 Optimisation of regexp engine string comparison work
The C API function for case-insensitive comparison of strings (which
is used heavily by the regexp engine) was substantially refactored and
optimised -- and its documentation much improved as a free bonus.
=head2 Regular expression compilation speed-up
Compiling regular expressions has been made faster when upgrading
the regex to utf8 is necessary but this isn't known when the compilation begins.
=head2 String appending is 100 times faster
When doing a lot of string appending, perls built to use the system's
C could end up allocating a lot more memory than needed in a
inefficient way.
C, the function used to allocate more memory if necessary
when appending to a string, has been taught to round up the memory
it requests to a certain geometric progression, making it much faster on
certain platforms and configurations. On Win32, it's now about 100 times
faster.
=head2 Eliminate C accessor functions under ithreads
When C was first developed, and interpreter state moved into
an interpreter struct, thread- and interpreter-local C variables
were defined as macros that called accessor functions (returning the
address of the value) outside the Perl core. The intent was to allow
members within the interpreter struct to change size without breaking
binary compatibility, so that bug fixes could be merged to a maintenance
branch that necessitated such a size change. This mechanism was redundant
and penalised well-behaved code. It has been removed.
=head2 Freeing weak references
When there are many weak references to an object, freeing that object
can under some circumstances take O(I) time to free, where
I is the number of references. The circumstances in which this can happen
have been reduced [perl #75254]
=head2 Lexical array and hash assignments
An earlier optimisation to speed up C and
C assignments caused a bug and was disabled in Perl 5.12.0.
Now we have found another way to speed up these assignments [perl #82110].
=head2 C<@_> uses less memory
Previously, C<@_> was allocated for every subroutine at compile time with
enough space for four entries. Now this allocation is done on demand when
the subroutine is called [perl #72416].
=head2 Size optimisations to SV and HV structures
C has been eliminated from C, saving 1 IV per hash and
on some systems will cause C to become cache-aligned. To avoid
this memory saving causing a slowdown elsewhere, boolean use of C
now calls C instead (which is equivalent), so while the fill
data when actually required are now calculated on demand, cases when
this needs to be done should be rare.
The order of structure elements in SV bodies has changed. Effectively,
the NV slot has swapped location with STASH and MAGIC. As all access to
SV members is via macros, this should be completely transparent. This
change allows the space saving for PVHVs documented above, and may reduce
the memory allocation needed for PVIVs on some architectures.
C, C, and C now allocate only the parts of the C body
they actually use, saving some space.
Scalars containing regular expressions now allocate only the part of the C
body they actually use, saving some space.
=head2 Memory consumption improvements to Exporter
The C<@EXPORT_FAIL> AV is no longer created unless needed, hence neither is
the typeglob backing it. This saves about 200 bytes for every package that
uses Exporter but doesn't use this functionality.
=head2 Memory savings for weak references
For weak references, the common case of just a single weak reference
per referent has been optimised to reduce the storage required. In this
case it saves the equivalent of one small Perl array per referent.
=head2 C<%+> and C<%-> use less memory
The bulk of the C module used to be in the Perl
core. It has now been moved to an XS module to reduce overhead for
programs that do not use C<%+> or C<%->.
=head2 Multiple small improvements to threads
The internal structures of threading now make fewer API calls and fewer
allocations, resulting in noticeably smaller object code. Additionally,
many thread context checks have been deferred so they're done only
as needed (although this is only possible for non-debugging builds).
=head2 Adjacent pairs of nextstate opcodes are now optimized away
Previously, in code such as
use constant DEBUG => 0;
sub GAK {
warn if DEBUG;
print "stuff\n";
}
the ops for C would be folded to a C op (C), but
the C op would remain, resulting in a runtime op dispatch of
C, C, etc.
The execution of a sequence of C ops is indistinguishable from just
the last C op so the peephole optimizer now eliminates the first of
a pair of C ops except when the first carries a label, since labels
must not be eliminated by the optimizer, and label usage isn't conclusively known
at compile time.
=head1 Modules and Pragmata
=head2 New Modules and Pragmata
=over 4
=item *
L 0.003 has been added as a dual-life module. It supports a
subset of YAML sufficient for reading and writing F and F files
included with CPAN distributions or generated by the module installation
toolchain. It should not be used for any other general YAML parsing or
generation task.
=item *
L version 2.110440 has been added as a dual-life module. It
provides a standard library to read, interpret and write CPAN distribution
metadata files (like F and F that describe a
distribution, its contents, and the requirements for building it and
installing it. The latest CPAN distribution metadata specification is
included as L and notes on changes in the specification
over time are given in L.
=item *
L 0.012 has been added as a dual-life module. It is a very
small, simple HTTP/1.1 client designed for simple GET requests and file
mirroring. It has been added so that F and L can
"bootstrap" HTTP access to CPAN using pure Perl without relying on external
binaries like L or L.
=item *
L 2.27105 has been added as a dual-life module to allow CPAN
clients to read F files in CPAN distributions.
=item *
L 1.000004 has been added as a dual-life module. It gathers
package and POD information from Perl module files. It is a standalone module
based on L for use by other module installation
toolchain components. L has been deprecated in
favor of this module instead.
=item *
L 1.002 has been added as a dual-life module. It maps Perl
operating system names (like "dragonfly" or "MSWin32") to more generic types
with standardized names (like "Unix" or "Windows"). It has been refactored
out of L and L and consolidates such mappings into
a single location for easier maintenance.
=item *
The following modules were added by the L
upgrade. See below for details.
L
L
L
L
L
L
=item *
L version 0.101020 has been added as a dual-life
module. It provides a standard library to model and manipulates module
prerequisites and version constraints defined in L.
=back
=head2 Updated Modules and Pragma
=over 4
=item *
L has been upgraded from version 0.12 to 0.14.
=item *
L has been upgraded from version 0.38 to 0.48.
Updates since 0.38 include: a safe print method that guards
L from changes to C<$\>; a fix to the tests when run in core
Perl; support for TZ files; a modification for the lzma
logic to favour L; and a fix
for an issue with NetBSD-current and its new L
executable.
=item *
L