[feature] strict and warnings optional extensions

[Grinnz]

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.

[leonerd]

An excellent idea. Over the years I have thought up a few things I thought ought to be strict flags, and always been stuck for not being able to add them.

For example, my own no stringification ought really to be in core, perhaps as use strict 'strings'.

https://metacpan.org/pod/release/PEVANS/stringification-0.01_004/lib/stringification.pm

Other thoughts we've had over the years are that maybe no indirect ought to have been use strict 'direct', or the newer no feature 'bareword::filehandles'; could have been a much nicer use strict 'filehandles';.

[Grinnz]

Cross-posted to perl5-porters: https://www.nntp.perl.org/group/perl.perl5.porters/2021/02/msg259029.html

[yuki-kimoto]

use strict 'direct'

use strict 'filehandles';

is natural for me rather than "no indirect" and no feature 'bareword::filehandles'

because this is things related to syntax.

[leonerd]

This idea also recently discussed on perl5-porters@:

https://www.nntp.perl.org/group/perl.perl5.porters/2021/11/msg261932.html

[dboehmer]

use strict 'direct'

use strict 'filehandles';

is natural for me rather than "no indirect" and no feature 'bareword::filehandles'

I feel like use strict 'direct' would require me to write code that doesn’t match the old indirect syntax. With no feature 'indirect' it disables the feature in Perl and I can write without worrying it might be misinterpreted as indirect object syntax. For example I regularly write in test files

ok my_function(), "my_function() works";

This doesn’t work if indirect object syntax is prohibited in code. At least I don’t want that.

[dboehmer]

I hope this is not out of scope for this issue:

I currently have the problem that my app’s base module enables strict and warnings but disabled a selected warning. Some modules like Moose and Test2::V0 will automatically import warnings for you which is a good thing. But this enables all warnings across the board.

If the warnings pragma was to be revisited like proposed above I suggest these rules:

• use warnings
  • if warnings wasn’t loaded before or no warnings are enabled at all (I am not sure which one can be detected or if they can be distinguished), warnings is loaded and (S) (D) are enabled
  • if warnings was already loaded and any warning from (S) (D) (W) is enabled, do not change anything
• use warnings 'all'
  • enables (S) (D) (W)
  • I am not sure about the proposed (O) 🤷‍♂️

[Grinnz]

That would unfortunately be an incompatible change, and I would consider it out of scope for this request. This request requires that all existing behavior is maintained, only a new category is added, and warnings continue to be put in the appropriate category to behave as expected.

It's up to modules like Moose to preserve the current status of warnings if they desire so.