This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Revert discouragement of fatal warnings
authorRicardo Signes <rjbs@cpan.org>
Tue, 17 Mar 2015 17:28:31 +0000 (13:28 -0400)
committerRicardo Signes <rjbs@cpan.org>
Tue, 17 Mar 2015 17:29:19 +0000 (13:29 -0400)
...at least for now.

This reverts commits 0d314ba30623b19c36dfc97ac4b6ecb94cb406f4
and ce3778a3796be3e4604ed9b3671ea624c5affe0b.

lib/warnings.pm
pod/perldelta.pod
regen/warnings.pl

index 765f60d..cad00ea 100644 (file)
@@ -5,7 +5,7 @@
 
 package warnings;
 
-our $VERSION = '1.32';
+our $VERSION = '1.31';
 
 # Verify that we're called correctly so that warnings will work.
 # see also strict.pm.
@@ -882,37 +882,7 @@ X<warning, fatal>
 
 The presence of the word "FATAL" in the category list will escalate any
 warnings detected from the categories specified in the lexical scope
-into fatal errors.
-
-B<NOTE:> Use of FATAL warnings is officially B<discouraged>.  Fatalizing
-warnings can, in some circumstances, leave the interpreter in an
-inconsistent internal state.  Given the many L<current and historical
-problems with FATAL warnings
-|http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg225235.html>
-and the general fragility of this feature, the Perl5 development team
-believes that FATAL warnings should not be used.
-
-Moreover, users of FATAL warnings, especially those using
-C<< FATAL => 'all' >> should be fully aware that they are risking future
-portability of their programs by doing so.  Perl makes absolutely no
-commitments to not introduce new warnings or warnings categories in the
-future; indeed, we explicitly reserve the right to do so.  Code that may
-not warn now may warn in a future release of Perl if the Perl5 development
-team deems it in the best interests of the community to do so.  Should code
-using FATAL warnings break due to the introduction of a new warning we will
-NOT consider it an incompatible change.  Users of FATAL warnings should
-take special caution during upgrades to check to see if their code triggers
-any new warnings and should pay particular attention to the fine print of
-the documentation of the features they use to ensure they do not exploit
-features that are documented as risky, deprecated, or unspecified, or where
-the documentation says "so don't do that", or anything with the same sense
-and spirit.  Use of such features in combination with FATAL warnings is
-ENTIRELY AT THE USER'S RISK.
-
-The following documentation describes the operation of FATAL warnings and
-is provided solely as a reference for use with legacy code.
-
-In the code below, the use of C<time>, C<length>
+into fatal errors.  In the code below, the use of C<time>, C<length>
 and C<join> can all produce a C<"Useless use of xxx in void context">
 warning.
 
@@ -965,6 +935,24 @@ C<< use warnings 'FATAL'; >>, C<< use warnings 'NONFATAL'; >> and
 C<< no warnings 'FATAL'; >> was unspecified; they did not behave as if
 they included the C<< => 'all' >> portion.  As of 5.20, they do.)
 
+B<NOTE:> Users of FATAL warnings, especially
+those using C<< FATAL => 'all' >>
+should be fully aware that they are risking future portability of their
+programs by doing so.  Perl makes absolutely no commitments to not
+introduce new warnings, or warnings categories in the future, and indeed
+we explicitly reserve the right to do so.  Code that may not warn now may
+warn in a future release of Perl if the Perl5 development team deems it
+in the best interests of the community to do so.  Should code using FATAL
+warnings break due to the introduction of a new warning we will NOT
+consider it an incompatible change.  Users of FATAL warnings should take
+special caution during upgrades to check to see if their code triggers
+any new warnings and should pay particular attention to the fine print of
+the documentation of the features they use to ensure they do not exploit
+features that are documented as risky, deprecated, or unspecified, or where
+the documentation says "so don't do that", or anything with the same sense
+and spirit.  Use of such features in combination with FATAL warnings is
+ENTIRELY AT THE USER'S RISK.
+
 =head2 Reporting Warnings from a Module
 X<warning, reporting> X<warning, registering>
 
index 4cc2c19..be7aaa4 100644 (file)
@@ -49,10 +49,6 @@ XXX For a release on a stable branch, this section aspires to be:
 
 XXX Any deprecated features, syntax, modules etc. should be listed here.
 
-=head2 FATAL warnings are now discouraged
-
-Cautions against use of FATAL warnings have been strengthened.
-
 =head2 Module removals
 
 XXX Remove this section if inapplicable.
@@ -240,10 +236,6 @@ L<utf8> has been upgraded from version 1.14 to 1.15.
 
 L<XS::APItest> has been upgraded from version 0.70 to 0.71.
 
-=item *
-
-L<warnings> has been upgraded from version 1.31 to 1.32.
-
 =back
 
 =head2 Removed Modules and Pragmata
index db9cc25..be6466a 100644 (file)
@@ -483,7 +483,7 @@ read_only_bottom_close_and_rename($pm);
 __END__
 package warnings;
 
-our $VERSION = '1.32';
+our $VERSION = '1.31';
 
 # Verify that we're called correctly so that warnings will work.
 # see also strict.pm.
@@ -998,37 +998,7 @@ X<warning, fatal>
 
 The presence of the word "FATAL" in the category list will escalate any
 warnings detected from the categories specified in the lexical scope
-into fatal errors.
-
-B<NOTE:> Use of FATAL warnings is officially B<discouraged>.  Fatalizing
-warnings can, in some circumstances, leave the interpreter in an
-inconsistent internal state.  Given the many L<current and historical
-problems with FATAL warnings
-|http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg225235.html>
-and the general fragility of this feature, the Perl5 development team
-believes that FATAL warnings should not be used.
-
-Moreover, users of FATAL warnings, especially those using
-C<< FATAL => 'all' >> should be fully aware that they are risking future
-portability of their programs by doing so.  Perl makes absolutely no
-commitments to not introduce new warnings or warnings categories in the
-future; indeed, we explicitly reserve the right to do so.  Code that may
-not warn now may warn in a future release of Perl if the Perl5 development
-team deems it in the best interests of the community to do so.  Should code
-using FATAL warnings break due to the introduction of a new warning we will
-NOT consider it an incompatible change.  Users of FATAL warnings should
-take special caution during upgrades to check to see if their code triggers
-any new warnings and should pay particular attention to the fine print of
-the documentation of the features they use to ensure they do not exploit
-features that are documented as risky, deprecated, or unspecified, or where
-the documentation says "so don't do that", or anything with the same sense
-and spirit.  Use of such features in combination with FATAL warnings is
-ENTIRELY AT THE USER'S RISK.
-
-The following documentation describes the operation of FATAL warnings and
-is provided solely as a reference for use with legacy code.
-
-In the code below, the use of C<time>, C<length>
+into fatal errors.  In the code below, the use of C<time>, C<length>
 and C<join> can all produce a C<"Useless use of xxx in void context">
 warning.
 
@@ -1081,6 +1051,24 @@ C<< use warnings 'FATAL'; >>, C<< use warnings 'NONFATAL'; >> and
 C<< no warnings 'FATAL'; >> was unspecified; they did not behave as if
 they included the C<< => 'all' >> portion.  As of 5.20, they do.)
 
+B<NOTE:> Users of FATAL warnings, especially
+those using C<< FATAL => 'all' >>
+should be fully aware that they are risking future portability of their
+programs by doing so.  Perl makes absolutely no commitments to not
+introduce new warnings, or warnings categories in the future, and indeed
+we explicitly reserve the right to do so.  Code that may not warn now may
+warn in a future release of Perl if the Perl5 development team deems it
+in the best interests of the community to do so.  Should code using FATAL
+warnings break due to the introduction of a new warning we will NOT
+consider it an incompatible change.  Users of FATAL warnings should take
+special caution during upgrades to check to see if their code triggers
+any new warnings and should pay particular attention to the fine print of
+the documentation of the features they use to ensure they do not exploit
+features that are documented as risky, deprecated, or unspecified, or where
+the documentation says "so don't do that", or anything with the same sense
+and spirit.  Use of such features in combination with FATAL warnings is
+ENTIRELY AT THE USER'S RISK.
+
 =head2 Reporting Warnings from a Module
 X<warning, reporting> X<warning, registering>