[ List each enhancement as a =head2 entry ]
+=head2 C<(?^...)> regex construct added to signify default modifiers
+
+A caret (also called a "cirumflex accent") C<"^"> immediately following
+a C<"(?"> in a regular expression now means that the subexpression is to
+not inherit the surrounding modifiers such as C</i>, but to revert to the
+Perl defaults. Any modifiers following the caret override the defaults.
+
+The stringification of regular expressions now uses this notation. The
+main purpose of this is to allow tests that rely on the stringification
+to not have to change when new modifiers are added. See
+L<perlre/Extended Patterns>.
+
+=head2 C<"d">, C<"l">, and C<"u"> regex modifiers added
+
+These modifiers are currently only available within a C<(?...)> construct.
+
+The C<"l"> modifier says to compile the regular expression as if it were
+in the scope of C<use locale>, even if it is not.
+
+The C<"u"> modifier currently does nothing.
+
+The C<"d"> modifier is used in the scope of C<use locale> to compile the
+regular expression as if it were not in that scope.
+See L<perlre/(?dlupimsx-imsx)>.
+
=head1 Security
XXX Any security-related notices go here. In particular, any security
=head1 Incompatible Changes
-XXX For a release on a stable branch, this section aspires to be:
+=head2 Stringification of regexes has changed
+
+Default regular expression modifiers are now notated by using
+C<(?^...)>. Code relying on the old stringification will fail. The
+purpose of this is so that when new modifiers are added, such code will
+not have to change, as the stringification will automatically
+incorporate the new modifiers.
+
+Code that needs to work properly with both old- and new-style regexes
+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>.
- There are no changes intentionally incompatible with 5.XXX.XXX. If any
- exist, they are bugs and reports are welcome.
+=head2 Regular expressions retain their localeness when interpolated
+
+Regular expressions compiled under C<"use locale"> now retain this when
+interpolated into a new regular expression compiled outside a
+C<"use locale">, and vice-versa.
+
+Previously, a regular expression interpolated into another one inherited
+the localeness of the surrounding one, 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 behavior.
[ List each incompatible change as a =head2 entry ]
=item *
-XXX
+C<File::DosGlob> has been upgraded from version 1.02 to 1.03.
+
+It allows patterns containing literal parentheses (they no longer need to
+be escaped). On Windows, it no longer adds an extra F<./> to the file names
+returned when the pattern is a relative glob with a drive specification,
+like F<c:*.pl>.
+
+=item *
+
+C<File::Find> has been upgraded from version 1.17 to 1.18.
+
+It improves handling of backslashes on Windows, so that paths such as
+F<c:\dir\/file> are no longer generated.
+
+=item *
+
+C<NEXT> has been upgraded from version 0.64 to 0.65.
+
+=item *
+
+C<PathTools> has been upgraded from version 3.31_01 to 3.33.
+
+=item *
+
+C<Unicode::Collate> has been upgraded from version 0.59 to 0.60
+
+=item *
+
+C<Unicode::Normalize> has been upgraded from version 1.06 to 1.07
=back
=item *
-XXX
+See L</Regular expressions retain their localeness when interpolated>,
+above.
=back
=item *
-XXX
+A regular expression match in the right-hand side of a global substitution
+(C<s///g>) that is in the same scope will no longer cause match variables
+to have the wrong values on subsequent iterations. This can happen when an
+array or hash subscript is interpolated in the right-hand side, as in
+C<s|(.)|@a{ print($1), /./ }|g>
+L<[perl #19078]|http://rt.perl.org/rt3//Public/Bug/Display.html?id=19078>.
+
+=item *
+
+Constant-folding used to cause
+
+ $text =~ ( 1 ? /phoo/ : /bear/)
+
+to turn into
+
+ $text =~ /phoo/
+
+at compile time. Now it correctly matches against C<$_>
+L<[perl #20444]|http://rt.perl.org/rt3//Public/Bug/Display.html?id=20444>.
+
+=item *
+
+Parsing Perl code (either with string C<eval> or by loading modules) from
+within a C<UNITCHECK> block no longer causes the interpreter to crash
+L<[perl #70614]|http://rt.perl.org/rt3//Public/Bug/Display.html?id=70614>.
+
+=item *
+
+When C<-d> is used on the shebang (C<#!>) line, the debugger now has access
+to the lines of the main program. In the past, this sometimes worked and
+sometimes did not, depending on what order things happened to be arranged
+in memory.
=back
https://perl5.git.perl.org / perl5.git / blobdiff