1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
|
=head1 NAME
perldelta - what is new for perl v5.11.0
=head1 DESCRIPTION
This document describes differences between the 5.10.0 and the 5.11.0
development releases.
=head1 Incompatible Changes
=head2 Switch statement changes
The handling of complex expressions by the C<given>/C<when> switch
statement has been enhanced. There are two new cases where C<when> now
interprets its argument as a boolean, instead of an expression to be used
in a smart match:
=over 4
=item flip-flop operators
The C<..> and C<...> flip-flop operators are evaluated in boolean context,
following their usual semantics; see L<perlop/"Range Operators">.
=item defined-or operator
A compound expression involving the defined-or operator, as in
C<when (expr1 // expr2)>, will be treated as boolean if the first
expression is boolean. (This just extends the existing rule that applies
to the regular or operator, as in C<when (expr1 || expr2)>.)
=back
The next paragraph details more changes brought to the semantics to
the smart match operator, that naturally also modify the behaviour
of the switch statements where smart matching is implicitly used.
=head2 Smart match changes
=head3 Changes to type-based dispatch
The smart match operator C<~~> is no longer commutative. The behaviour of
a smart match now depends primarily on the type of its right hand
argument. Moreover, its semantics has been adjusted for greater
consistency or usefulness in several cases. While the general backwards
compatibility is maintained, several changes must be noted:
=over 4
=item *
Code references with an empty prototype are no longer treated specially.
They are passed an argument like the other code references (even if they
choose to ignore it).
=item *
C<%hash ~~ sub {}> and C<@array ~~ sub {}> now test that the subroutine
returns a true value for each key of the hash (or element of the
array), instead of passing the whole hash or array as a reference to
the subroutine.
=item *
Due to the commutativity breakage, code references are no longer
treated specially when appearing on the left of the C<~~> operator,
but like any vulgar scalar.
=item *
C<undef ~~ %hash> is always false (since C<undef> can't be a key in a
hash). No implicit conversion to C<""> is done (as was the case in perl
5.10.0).
=item *
C<$scalar ~~ @array> now always distributes the smart match across the
elements of the array. It's true if one element in @array verifies
C<$scalar ~~ $element>. This is a generalization of the old behaviour
that tested whether the array contained the scalar.
=back
The full dispatch table for the smart match operator is given in
L<perlsyn/"Smart matching in detail">.
=head3 Smart match and overloading
According to the rule of dispatch based on the rightmost argument type,
when an object overloading C<~~> appears on the right side of the
operator, the overload routine will always be called (with a 3rd argument
set to a true value, see L<overload>.) However, when the object will
appear on the left, the overload routine will be called only when the
rightmost argument is a simple scalar. This way distributivity of smart match
across arrays is not broken, as well as the other behaviours with complex
types (coderefs, hashes, regexes). Thus, writers of overloading routines
for smart match mostly need to worry only with comparing against a scalar,
and possibly with stringification overloading; the other common cases
will be automatically handled consistently.
C<~~> will now refuse to work on objects that do not overload it (in order
to avoid relying on the object's underlying structure).
=head1 Core Enhancements
=head2 The C<overloading> pragma
This pragma allows you to lexically disable or enable overloading
for some or all operations. (Yuval Kogman)
=head2 C<\N> regex escape
A new regex escape has been added, C<\N>. It will match any character that
is not a newline, independently from the presence or absence of the single
line match modifier C</s>. (If C<\N> is followed by an opening brace and
by a letter, perl will still assume that a Unicode character name is
coming, so compatibility is preserved.) (Rafael Garcia-Suarez)
=head2 Parallel tests
The core distribution can now run its regression tests in parallel on
Unix-like platforms. Instead of running C<make test>, set C<TEST_JOBS> in
your environment to the number of tests to run in parallel, and run
C<make test_harness>. On a Bourne-like shell, this can be done as
TEST_JOBS=3 make test_harness # Run 3 tests in parallel
An environment variable is used, rather than parallel make itself, because
L<TAP::Harness> needs to be able to schedule individual non-conflicting test
scripts itself, and there is no standard interface to C<make> utilities to
interact with their job schedulers.
=head1 Modules and Pragmata
=head2 Pragmata Changes
=over 4
=item C<overloading>
See L</"The C<overloading> pragma"> above.
=back
=head1 Utility Changes
=head1 Documentation
=head1 Performance Enhancements
=head1 Installation and Configuration Improvements
=head1 Selected Bug Fixes
=over 4
=item C<-I> on shebang line now adds directories in front of @INC
as documented, and as does C<-I> when specified on the command-line.
(Renée Bäcker)
=back
=head1 New or Changed Diagnostics
=head1 Changed Internals
=head1 Known Problems
=head2 Platform Specific Problems
=head1 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 http://bugs.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 B<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 C<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 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.
=head1 SEE ALSO
The F<Changes> file for exhaustive details on what changed.
The F<INSTALL> file for how to build Perl.
The F<README> file for general stuff.
The F<Artistic> and F<Copying> files for copyright information.
=cut
|
