This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
perldelta: more consistent formatting of fullstops
[perl5.git] / pod / perldelta.pod
index cf20b57..e6105bb 100644 (file)
@@ -489,12 +489,12 @@ See L</Internal Changes>.
 
 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
 
@@ -511,7 +511,7 @@ different, anomalous behavior than their use in all other
 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
@@ -589,7 +589,8 @@ was compiled at run time as happens in cases like these two:
   $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
@@ -606,7 +607,7 @@ In the following:
     # 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
@@ -620,10 +621,10 @@ hashes that drastically reduce their memory usage overhead.
 
 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
@@ -633,8 +634,9 @@ If you assign a typeglob to a scalar variable:
     $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.
@@ -649,17 +651,17 @@ has been modified to make a new immutable glob if its operand is a glob
 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