view release on metacpan or  search on metacpan

pod/perl5160delta.pod  view on Meta::CPAN

=encoding utf8

=head1 NAME

perl5160delta - what is new for perl v5.16.0

=head1 DESCRIPTION

This document describes differences between the 5.14.0 release and
the 5.16.0 release.

If you are upgrading from an earlier release such as 5.12.0, first read
L<perl5140delta>, which describes differences between 5.12.0 and
5.14.0.

Some bug fixes in this release have been backported to later
releases of 5.14.x.  Those are indicated with the 5.14.x version in
parentheses.

=head1 Notice

With the release of Perl 5.16.0, the 5.12.x series of releases is now out of
its support period.  There may be future 5.12.x releases, but only in the
event of a critical security issue.  Users of Perl 5.12 or earlier should
consider upgrading to a more recent release of Perl.

This policy is described in greater detail in
L<perlpolicy|perlpolicy/MAINTENANCE AND SUPPORT>.

=head1 Core Enhancements

=head2 C<use I<VERSION>>

As of this release, version declarations like C<use v5.16> now disable
all features before enabling the new feature bundle.  This means that
the following holds true:

    use 5.016;
    # only 5.16 features enabled here
    use 5.014;
    # only 5.14 features enabled here (not 5.16)

C<use v5.12> and higher continue to enable strict, but explicit C<use
strict> and C<no strict> now override the version declaration, even
when they come first:

    no strict;
    use 5.012;
    # no strict here

There is a new ":default" feature bundle that represents the set of
features enabled before any version declaration or C<use feature> has
been seen.  Version declarations below 5.10 now enable the ":default"
feature set.  This does not actually change the behavior of C<use
v5.8>, because features added to the ":default" set are those that were
traditionally enabled by default, before they could be turned off.

C<< no feature >> now resets to the default feature set.  To disable all
features (which is likely to be a pretty special-purpose request, since
it presumably won't match any named set of semantics) you can now
write C<< no feature ':all' >>.

C<$[> is now disabled under C<use v5.16>.  It is part of the default
feature set and can be turned on or off explicitly with C<use feature
'array_base'>.

=head2 C<__SUB__>

The new C<__SUB__> token, available under the C<current_sub> feature
(see L<feature>) or C<use v5.16>, returns a reference to the current
subroutine, making it easier to write recursive closures.

=head2 New and Improved Built-ins

=head3 More consistent C<eval>

The C<eval> operator sometimes treats a string argument as a sequence of
characters and sometimes as a sequence of bytes, depending on the
internal encoding.  The internal encoding is not supposed to make any
difference, but there is code that relies on this inconsistency.

The new C<unicode_eval> and C<evalbytes> features (enabled under C<use
5.16.0>) resolve this.  The C<unicode_eval> feature causes C<eval
$string> to treat the string always as Unicode.  The C<evalbytes>
features provides a function, itself called C<evalbytes>, which
evaluates its argument always as a string of bytes.

These features also fix oddities with source filters leaking to outer
dynamic scopes.

See L<feature> for more detail.

=head3 C<substr> lvalue revamp

=for comment Does this belong here, or under Incompatible Changes?

When C<substr> is called in lvalue or potential lvalue context with two
or three arguments, a special lvalue scalar is returned that modifies
the original string (the first argument) when assigned to.

Previously, the offsets (the second and third arguments) passed to
C<substr> would be converted immediately to match the string, negative
offsets being translated to positive and offsets beyond the end of the
string being truncated.

Now, the offsets are recorded without modification in the special
lvalue scalar that is returned, and the original string is not even
looked at by C<substr> itself, but only when the returned lvalue is
read or modified.

These changes result in an incompatible change:

If the original string changes length after the call to C<substr> but
before assignment to its return value, negative offsets will remember
their position from the end of the string, affecting code like this:

    my $string = "string";
    my $lvalue = \substr $string, -4, 2;
    print $$lvalue, "\n"; # prints "ri"
    $string = "bailing twine";
    print $$lvalue, "\n"; # prints "wi"; used to print "il"