You are viewing the version of this documentation from Perl 5.22.0. View the latest version

CONTENTS

NAME

perl5216delta - what is new for perl v5.21.6

DESCRIPTION

This document describes differences between the 5.21.5 release and the 5.21.6 release.

If you are upgrading from an earlier release such as 5.21.4, first read perl5215delta, which describes differences between 5.21.4 and 5.21.5.

Core Enhancements

List form of pipe open implemented for Win32

The list form of pipe:

open my $fh, "-|", "program", @arguments;

is now implemented on Win32. It has the same limitations as system LIST on Win32, since the Win32 API doesn't accept program arguments as a list.

Assignment to list repetition

(...) x ... can now be used within a list that is assigned to, as long as the left-hand side is a valid lvalue. This allows (undef,undef,$foo) = that_function() to be written as ((undef)x2, $foo) = that_function().

close now sets $!

When an I/O error occurs, the fact that there has been an error is recorded in the handle. close returns false for such a handle. Previously, the value of $! would be untouched by close, so the common convention of writing close $fh or die $! did not work reliably. Now the handle records the value of $!, too, and close restores it.

Deprecations

Use of non-graphic characters in single-character variable names

The syntax for single-character variable names is more lenient than for longer variable names, allowing the one-character name to be a punctuation character or even invisible (a non-graphic). Perl v5.20 deprecated the ASCII-range controls as such a name. Now, all non-graphic characters that formerly were allowed are deprecated. The practical effect of this occurs only when not under "use utf8", and affects just the C1 controls (code points 0x80 through 0xFF), NO-BREAK SPACE, and SOFT HYPHEN.

Inlining of sub () { $var } with observable side-effects

In many cases Perl makes sub () { $var } into an inlinable constant subroutine, capturing the value of $var at the time the sub expression is evaluated. This can break the closure behaviour in those cases where $var is subsequently modified. The subroutine won't return the new value.

This usage is now deprecated in those cases where the variable could be modified elsewhere. Perl detects those cases and emits a deprecation warning. Such code will likely change in the future and stop producing a constant.

If your variable is only modified in the place where it is declared, then Perl will continue to make the sub inlinable with no warnings.

sub make_constant {
    my $var = shift;
    return sub () { $var }; # fine
}

sub make_constant_deprecated {
    my $var;
    $var = shift;
    return sub () { $var }; # deprecated
}

sub make_constant_deprecated2 {
    my $var = shift;
    log_that_value($var); # could modify $var
    return sub () { $var }; # deprecated
}

In the second example above, detecting that $var is assigned to only once is too hard to detect. That it happens in a spot other than the my declaration is enough for Perl to find it suspicious.

This deprecation warning happens only for a simple variable for the body of the sub. (A BEGIN block or use statement inside the sub is ignored, because it does not become part of the sub's body.) For more complex cases, such as sub () { do_something() if 0; $var } the behaviour has changed such that inlining does not happen if the variable is modifiable elsewhere. Such cases should be rare.

Performance Enhancements

Modules and Pragmata

Updated Modules and Pragmata

Documentation

Changes to Existing Documentation

"Identifier parsing" in perldata

Diagnostics

The following additions or changes have been made to diagnostic output, including warnings and fatal error messages. For the complete list of diagnostic messages, see perldiag.

New Diagnostics

New Warnings

Changes to Existing Diagnostics

Configuration and Compilation

Platform Support

Platform-Specific Notes

Win32

Internal Changes

Selected Bug Fixes

Known Problems

Errata From Previous Releases

Acknowledgements

Perl 5.21.6 represents approximately 4 weeks of development since Perl 5.21.5 and contains approximately 60,000 lines of changes across 920 files from 25 authors.

Excluding auto-generated files, documentation and release tools, there were approximately 48,000 lines of changes to 630 .pm, .t, .c and .h files.

Perl continues to flourish into its third decade thanks to a vibrant community of users and developers. The following people are known to have contributed the improvements that became Perl 5.21.6:

Aaron Crane, Abigail, Andrew Fresh, Andy Dougherty, Brian Fraser, Chad Granum, Chris 'BinGOs' Williams, Craig A. Berry, Daniel Dragan, David Mitchell, Doug Bell, Father Chrysostomos, Glenn D. Golden, James E Keenan, Jarkko Hietaniemi, Jim Cromie, Karen Etheridge, Karl Williamson, Lukas Mai, Ricardo Signes, Shlomi Fish, Slaven Rezic, Steve Hay, Tony Cook, Yaroslav Kuzmin.

The list above is almost certainly incomplete as it is automatically generated from version control history. In particular, it does not include the names of the (very much appreciated) contributors who reported issues to the Perl bug tracker.

Many of the changes included in this version originated in the CPAN modules included in Perl's core. We're grateful to the entire CPAN community for helping Perl to flourish.

For a more complete list of all of Perl's historical contributors, please see the AUTHORS file in the Perl source distribution.

Reporting Bugs

If you find what you think is a bug, you might check the articles recently posted to the comp.lang.perl.misc newsgroup and the perl bug database at https://rt.perl.org/ . There may also be information at http://www.perl.org/ , the Perl Home Page.

If you believe you have an unreported bug, please run the perlbug program included with your release. Be sure to trim your bug down to a tiny but sufficient test case. Your bug report, along with the output of perl -V, will be sent off to perlbug@perl.org to be analysed by the Perl porting team.

If the bug you are reporting has security implications, which make it inappropriate to send to a publicly archived mailing list, then please send it to perl5-security-report@perl.org. This points to a closed subscription unarchived mailing list, which includes all the core committers, who will be able to help assess the impact of issues, figure out a resolution, and help co-ordinate the release of patches to mitigate or fix the problem across all platforms on which Perl is supported. Please only use this address for security issues in the Perl core, not for modules independently distributed on CPAN.

SEE ALSO

The Changes file for an explanation of how to view exhaustive details on what changed.

The INSTALL file for how to build Perl.

The README file for general stuff.

The Artistic and Copying files for copyright information.