Commit | Line | Data |
---|---|---|
7120b314 NC |
1 | =head1 NAME |
2 | ||
3 | perldelta - what is new for perl v5.11.0 | |
4 | ||
5 | =head1 DESCRIPTION | |
6 | ||
7 | This document describes differences between the 5.10.0 and the 5.11.0 | |
9948897e | 8 | development releases. |
7120b314 NC |
9 | |
10 | =head1 Incompatible Changes | |
11 | ||
8b8da387 RGS |
12 | =head2 Switch statement changes |
13 | ||
14 | The handling of complex expressions by the C<given>/C<when> switch | |
1710b4c0 | 15 | statement has been enhanced. There are two new cases where C<when> now |
412304fb | 16 | interprets its argument as a boolean, instead of an expression to be used |
8b8da387 RGS |
17 | in a smart match: |
18 | ||
19 | =over 4 | |
20 | ||
8b8da387 RGS |
21 | =item flip-flop operators |
22 | ||
98814a2b RGS |
23 | The C<..> and C<...> flip-flop operators are now evaluated in boolean |
24 | context, following their usual semantics; see L<perlop/"Range Operators">. | |
25 | ||
26 | Note that, as in perl 5.10.0, C<when (1..10)> will not work to test | |
27 | whether a given value is an integer between 1 and 10; you should use | |
28 | C<when ([1..10])> instead (note the array reference). | |
29 | ||
30 | However, contrary to 5.10.0, evaluating the flip-flop operators in boolean | |
31 | context ensures it can now be useful in a C<when()>, notably for | |
32 | implementing bistable conditions, like in: | |
33 | ||
34 | when (/^=begin/ .. /^=end/) { ... } | |
8b8da387 RGS |
35 | |
36 | =item defined-or operator | |
37 | ||
38 | A compound expression involving the defined-or operator, as in | |
39 | C<when (expr1 // expr2)>, will be treated as boolean if the first | |
40 | expression is boolean. (This just extends the existing rule that applies | |
41 | to the regular or operator, as in C<when (expr1 || expr2)>.) | |
42 | ||
43 | =back | |
44 | ||
98814a2b | 45 | The next section details more changes brought to the semantics to |
8b8da387 RGS |
46 | the smart match operator, that naturally also modify the behaviour |
47 | of the switch statements where smart matching is implicitly used. | |
48 | ||
49 | =head2 Smart match changes | |
50 | ||
51 | =head3 Changes to type-based dispatch | |
52 | ||
53 | The smart match operator C<~~> is no longer commutative. The behaviour of | |
54 | a smart match now depends primarily on the type of its right hand | |
ee18cc6c RGS |
55 | argument. Moreover, its semantics has been adjusted for greater |
56 | consistency or usefulness in several cases. While the general backwards | |
57 | compatibility is maintained, several changes must be noted: | |
8b8da387 RGS |
58 | |
59 | =over 4 | |
60 | ||
61 | =item * | |
62 | ||
63 | Code references with an empty prototype are no longer treated specially. | |
64 | They are passed an argument like the other code references (even if they | |
65 | choose to ignore it). | |
66 | ||
67 | =item * | |
68 | ||
69 | C<%hash ~~ sub {}> and C<@array ~~ sub {}> now test that the subroutine | |
9091a618 | 70 | returns a true value for each key of the hash (or element of the |
8b8da387 RGS |
71 | array), instead of passing the whole hash or array as a reference to |
72 | the subroutine. | |
73 | ||
74 | =item * | |
75 | ||
ee18cc6c RGS |
76 | Due to the commutativity breakage, code references are no longer |
77 | treated specially when appearing on the left of the C<~~> operator, | |
78 | but like any vulgar scalar. | |
79 | ||
80 | =item * | |
81 | ||
8b8da387 RGS |
82 | C<undef ~~ %hash> is always false (since C<undef> can't be a key in a |
83 | hash). No implicit conversion to C<""> is done (as was the case in perl | |
84 | 5.10.0). | |
85 | ||
86 | =item * | |
87 | ||
88 | C<$scalar ~~ @array> now always distributes the smart match across the | |
89 | elements of the array. It's true if one element in @array verifies | |
90 | C<$scalar ~~ $element>. This is a generalization of the old behaviour | |
91 | that tested whether the array contained the scalar. | |
92 | ||
93 | =back | |
94 | ||
95 | The full dispatch table for the smart match operator is given in | |
96 | L<perlsyn/"Smart matching in detail">. | |
97 | ||
98 | =head3 Smart match and overloading | |
99 | ||
100 | According to the rule of dispatch based on the rightmost argument type, | |
101 | when an object overloading C<~~> appears on the right side of the | |
102 | operator, the overload routine will always be called (with a 3rd argument | |
103 | set to a true value, see L<overload>.) However, when the object will | |
104 | appear on the left, the overload routine will be called only when the | |
9091a618 | 105 | rightmost argument is a simple scalar. This way distributivity of smart match |
8b8da387 RGS |
106 | across arrays is not broken, as well as the other behaviours with complex |
107 | types (coderefs, hashes, regexes). Thus, writers of overloading routines | |
ee18cc6c RGS |
108 | for smart match mostly need to worry only with comparing against a scalar, |
109 | and possibly with stringification overloading; the other common cases | |
110 | will be automatically handled consistently. | |
8b8da387 RGS |
111 | |
112 | C<~~> will now refuse to work on objects that do not overload it (in order | |
665f5e98 RGS |
113 | to avoid relying on the object's underlying structure). (However, if the |
114 | object overloads the stringification or the numification operators, and | |
115 | if overload fallback is active, it will be used instead, as usual.) | |
8b8da387 | 116 | |
7120b314 NC |
117 | =head1 Core Enhancements |
118 | ||
ef55af2a | 119 | =head2 The C<overloading> pragma |
1839a850 RGS |
120 | |
121 | This pragma allows you to lexically disable or enable overloading | |
122 | for some or all operations. (Yuval Kogman) | |
123 | ||
71e9c532 RGS |
124 | =head2 C<\N> regex escape |
125 | ||
126 | A new regex escape has been added, C<\N>. It will match any character that | |
127 | is not a newline, independently from the presence or absence of the single | |
128 | line match modifier C</s>. (If C<\N> is followed by an opening brace and | |
129 | by a letter, perl will still assume that a Unicode character name is | |
130 | coming, so compatibility is preserved.) (Rafael Garcia-Suarez) | |
131 | ||
4b3db487 RGS |
132 | =head2 Implicit strictures |
133 | ||
134 | Using the C<use VERSION> syntax with a version number greater or equal | |
135 | to 5.11.0 will also lexically enable strictures just like C<use strict> | |
136 | would do (in addition to enabling features.) So, the following: | |
137 | ||
138 | use 5.11.0; | |
139 | ||
140 | will now imply: | |
141 | ||
142 | use strict; | |
143 | use feature ':5.11'; | |
144 | ||
5ee651a9 NC |
145 | =head2 Parallel tests |
146 | ||
147 | The core distribution can now run its regression tests in parallel on | |
148 | Unix-like platforms. Instead of running C<make test>, set C<TEST_JOBS> in | |
149 | your environment to the number of tests to run in parallel, and run | |
150 | C<make test_harness>. On a Bourne-like shell, this can be done as | |
151 | ||
152 | TEST_JOBS=3 make test_harness # Run 3 tests in parallel | |
153 | ||
154 | An environment variable is used, rather than parallel make itself, because | |
155 | L<TAP::Harness> needs to be able to schedule individual non-conflicting test | |
156 | scripts itself, and there is no standard interface to C<make> utilities to | |
157 | interact with their job schedulers. | |
158 | ||
044c880b RGS |
159 | =head2 The C<...> operator |
160 | ||
161 | A new operator, C<...>, nicknamed the Yada Yada operator, has been added. | |
162 | It is intended to mark placeholder code, that is not yet implemented. | |
163 | See L<perlop/"Yada Yada Operator">. (chromatic) | |
164 | ||
7120b314 NC |
165 | =head1 Modules and Pragmata |
166 | ||
1839a850 RGS |
167 | =head2 Pragmata Changes |
168 | ||
169 | =over 4 | |
170 | ||
171 | =item C<overloading> | |
172 | ||
173 | See L</"The C<overloading> pragma"> above. | |
174 | ||
175 | =back | |
176 | ||
02569b83 RGS |
177 | =head2 Selected Changes to Core Modules |
178 | ||
179 | =over 4 | |
180 | ||
181 | L<Carp> now includes all the necessary code to function. Previously, it | |
182 | used to be a lightweight placeholder that loaded the actual code from | |
183 | C<Carp::Heavy> on demand. C<Carp::Heavy> is now a simple, empty module | |
184 | kept for backwards compatibility for programs that used to pre-load it. | |
185 | ||
186 | =back | |
187 | ||
7120b314 NC |
188 | =head1 Utility Changes |
189 | ||
190 | =head1 Documentation | |
191 | ||
192 | =head1 Performance Enhancements | |
193 | ||
194 | =head1 Installation and Configuration Improvements | |
195 | ||
196 | =head1 Selected Bug Fixes | |
197 | ||
54ad55c5 RGS |
198 | =over 4 |
199 | ||
200 | =item C<-I> on shebang line now adds directories in front of @INC | |
201 | ||
202 | as documented, and as does C<-I> when specified on the command-line. | |
203 | (Renée Bäcker) | |
204 | ||
e2c0f81f DG |
205 | =item C<kill> is now fatal when called on non-numeric process identifiers |
206 | ||
207 | Previously, an 'undef' process identifier would be interpreted as a request to | |
208 | kill process "0", which would terminate the current process group on POSIX | |
209 | systems. Since process identifiers are always integers, killing a non-numeric | |
210 | process is now fatal. | |
211 | ||
fc46f0f6 FC |
212 | =item C<-C> on the shebang line is once more permitted |
213 | ||
214 | if it is also specified on the command line. C<-C> on the shebang line used | |
215 | to be a silent no-op I<if> it was not also on the command line, so perl | |
216 | 5.10.0 disallowed it, which broke some scripts. Now perl checks whether it | |
217 | is also on the command line and only dies if it is not. | |
218 | ||
54ad55c5 RGS |
219 | =back |
220 | ||
7120b314 NC |
221 | =head1 New or Changed Diagnostics |
222 | ||
223 | =head1 Changed Internals | |
224 | ||
225 | =head1 Known Problems | |
226 | ||
227 | =head2 Platform Specific Problems | |
228 | ||
229 | =head1 Reporting Bugs | |
230 | ||
231 | If you find what you think is a bug, you might check the articles | |
232 | recently posted to the comp.lang.perl.misc newsgroup and the perl | |
233 | bug database at http://bugs.perl.org/ . There may also be | |
234 | information at http://www.perl.org/ , the Perl Home Page. | |
235 | ||
236 | If you believe you have an unreported bug, please run the B<perlbug> | |
237 | program included with your release. Be sure to trim your bug down | |
238 | to a tiny but sufficient test case. Your bug report, along with the | |
239 | output of C<perl -V>, will be sent off to perlbug@perl.org to be | |
240 | analysed by the Perl porting team. | |
241 | ||
49f8307e NC |
242 | If the bug you are reporting has security implications, which make it |
243 | inappropriate to send to a publicly archived mailing list, then please send | |
244 | it to perl5-security-report@perl.org. This points to a closed subscription | |
245 | unarchived mailing list, which includes all the core committers, who be able | |
246 | to help assess the impact of issues, figure out a resolution, and help | |
247 | co-ordinate the release of patches to mitigate or fix the problem across all | |
248 | platforms on which Perl is supported. Please only use this address for security | |
249 | issues in the Perl core, not for modules independently distributed on CPAN. | |
250 | ||
7120b314 NC |
251 | =head1 SEE ALSO |
252 | ||
253 | The F<Changes> file for exhaustive details on what changed. | |
254 | ||
255 | The F<INSTALL> file for how to build Perl. | |
256 | ||
257 | The F<README> file for general stuff. | |
258 | ||
259 | The F<Artistic> and F<Copying> files for copyright information. | |
260 | ||
261 | =cut |