In L<perlunicode/"User-Defined Character Properties">, it says you can
create custom properties by defining subroutines whose names begin with
-"In" or "Is". However, Perl did not actually enforce that naming
-restriction, so \p{foo::bar} could call foo::bar() if it existed. Now this
+"In" or "Is". However, Perl did not actually enforce that naming
+restriction, so \p{foo::bar} could call foo::bar() if it existed. Now this
convention has been enforced.
Also, Perl no longer allows a tainted regular expression to invoke a
-user-defined property. It simply dies instead [perl #82616].
+user-defined property. It simply dies instead [perl #82616].
=head1 Incompatible Changes
double-quote-like contexts. Since 5.10.1, a deprecated warning message
has been raised when this happens. Now, all double-quote-like contexts
have the same behavior, namely to be equivalent to C<\x{100}> -
-C<\x{1FF}>, with no deprecation warning. Use of these values in the
+C<\x{1FF}>, with no deprecation warning. Use of these values in the
command line option C<"-0"> retains the current meaning to slurp input
files whole; previously, this was documented only for C<"-0777">. It is
recommended, however, because of various ambiguities, to use the new
$foo =~ $bar; # when $bar contains (?{...})
$foo =~ /$bar(?{ $finished = 1 })/;
-This was a bug, which has now been fixed. But it has the potential to break
+This was a bug, which has now been fixed. But
+it has the potential to break
any code that was relying on it.
=head2 Stashes and Package Variables
# here, @a refers again to the old, tied array
The new local array used to be made tied too, which was fairly pointless,
-and has now been fixed. This fix could however potentially cause a change
+and has now been fixed. This fix could however potentially cause a change
in behaviour of some code.
=head3 Stashes are now always defined
Calling defined on a stash has been deprecated since 5.6.0, warned on
lexicals since 5.6.0, and warned for stashes (and other package
-variables) since 5.12.0. C<defined %hash> has always exposed an
+variables) since 5.12.0. C<defined %hash> has always exposed an
implementation detail - emptying a hash by deleting all entries from it does
not make C<defined %hash> false, hence C<defined %hash> is not valid code to
-determine whether an arbitrary hash is empty. Instead, use the behaviour
+determine whether an arbitrary hash is empty. Instead, use the behaviour
that an empty C<%hash> always returns false in a scalar context.
=head3 Dereferencing typeglobs
$glob = *foo;
the glob that is copied to C<$glob> is marked with a special flag
-indicating that the glob is just a copy. This allows subsequent assignments
-to C<$glob> to overwrite the glob. The original glob, however, is
+indicating that the glob is just a copy. This
+allows subsequent assignments to C<$glob> to
+overwrite the glob. The original glob, however, is
immutable.
Many Perl operators did not distinguish between these two types of globs.
copy. This allows operators that make a distinction between globs and
scalars to be modified to treat only immutable globs as globs. (C<tie>,
C<tied> and C<untie> have been left as they are for compatibility's sake,
-but will warn. See L</Deprecations>.)
+but will warn. See L</Deprecations>.)
This causes an incompatible change in code that assigns a glob to the
-return value of C<*{}> when that operator was passed a glob copy. Take the
+return value of C<*{}> when that operator was passed a glob copy. Take the
following code, for instance:
$glob = *foo;
*$glob = *bar;
The C<*$glob> on the second line returns a new immutable glob. That new
-glob is made an alias to C<*bar>. Then it is discarded. So the second
+glob is made an alias to C<*bar>. Then it is discarded. So the second
assignment has no effect.
See L<http://rt.perl.org/rt3/Public/Bug/Display.html?id=77810> for even