develooper Front page | perl.perl5.porters | Postings from February 2021

strict and warnings optional extensions

Dan Book
February 7, 2021 23:06
strict and warnings optional extensions
Message ID:
Since they were introduced in early Perl 5, strict and warnings have
enabled the equivalent of all when used in the recommended use strict; and
use warnings; forms. There have occasionally been ideas of additional
behavior that would make sense for these pragmas to enable, but without
enabling them in the massive amount of existing code which currently enable
all implicitly or explicitly. So I propose that mechanisms be added for
"optional" strictures and warnings, which are not enabled by use strict;
use warnings;.

strict has three subpragmas: vars, refs, and subs. There is no all
category, but a bare use strict; enables these three items. So to add an
optional stricture, we would need a mechanism to add a subpragma which is
not enabled by a bare use strict;, and users could then simply use strict
'whatever'; to opt-in to the stricture for that scope. A flag to use strict
which would enable these additional strictures could be considered, but I
do not think it would be a good idea since such a flag would effectively be
restricted to whatever it enables the first time it's added.

warnings has hundreds of warning categories organized in a few
classifications, as described in perldiag.

* The (S) and (D) class warnings are enabled by default - they are
considered severe enough that all code should be subject to them, unless
explicitly disabled.
* The (W) class warnings are not enabled by default, but are enabled when
under use warnings 'all';, which is the same as use warnings;.

There is no policy against adding new warnings to these classifications at
any time - but there is an expectation for the warnings to be reasonable
for the classification they're added to, so as not to cause grief for users
who expected certain behavior.

So to add "optional warnings", we would need a new optional warnings
classification (O) which is not enabled by use warnings 'all'; or use
warnings;. Yes, this makes the 'all' category name misleading, but I assert
that this doesn't really matter, because very few people actually spell it
out. An 'optional' category name and a way to enable it in addition to
'all' could be reasonable for users who really want all possible warnings,
but this shouldn't necessarily be encouraged, because such 'optional'
warnings would be limited to those which are deemed too niche for the
userbase at large.

I am purposely describing only the user-facing API design, as the
implementation details are outside my expertise, but an important component
of making this happen.

Cross-posted to GitHub issue:

-Dan Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About