Corion has asked for the wisdom of the Perl Monks concerning the following question:

I've just released Future::HTTP using signatures. Basically, this needs the following stanza to tell Perl that I know what I'm doing:

no warnings 'experimental::signatures'; use feature 'signatures';

As I want to support versions of Perl older than 5.22 and also only use a restricted set of signature features, I also wrote Filter::signatures, which implements a very restricted version of signatures as a source filter.

The problem now arises when my code is run under (say) Perl 5.14. That version of Perl does not know about the experimental::signatures warning category. But I don't care about warnings not knowing about that category because if it doesn't know about a category, disabling that category can't make things worse. The following approaches don't work:

eval { no warnings 'experimental::signatures' };

This gives a compile time error as "no warnings" happens when the source code is parsed.

eval "no warnings 'experimental::signatures'";

This catches the error, but runs too late because the warnings get raised during compile time and then get disabled at runtime.

BEGIN { eval "no warnings 'experimental::signatures'"; }

This runs at the right time, but as the warnings are lexically scoped, the warnings only get disabled for the BEGIN block.

So far, I've settled on Filter::signatures simply disabling the exact statement of no warnings 'experimental::signatures'; when it finds it. This is the same approach the module already takes to defang use feature 'signatures'; on versions of Perl that don't have signature support. But that path leads down the ugly and very slippery slope of rewriting more and more of Perl code and I'd prefer to keep the modifications of the source filter as small as possible.

I guess my question boils down to how to disable a warning category for a complete package without wrapping the whole package in a BEGIN scope, and ideally without using a source filter...

Replies are listed 'Best First'.
Re: Optionally / safely disabling a warning category for a complete package
by haukex (Archbishop) on May 18, 2016 at 08:08 UTC

    Hi Corion,

    How about using if:

    no if $] >= 5.020, warnings => 'experimental::signatures';

    Inspired by perl5180delta.

    Update: Changed 5.022 to 5.020 since that's when signatures were added.

    Hope this helps,
    -- Hauke D

Re: Optionally / safely disabling a warning category for a complete package
by haukex (Archbishop) on May 18, 2016 at 09:59 UTC

    Hi Corion,

    It also seems to be possible that you add the following to Filter::signatures's import: warnings->unimport('experimental::signatures') if $] >= 5.020;

    Test code:

    Hope this helps,
    -- Hauke D

Re: Optionally / safely disabling a warning category for a complete package (magic numbers)
by tye (Sage) on May 18, 2016 at 14:55 UTC

    Sorry for not testing this (which would require multiple versions of Perl that I didn't already have handy). I suspect this will work based on prior similar code I've used:

    BEGIN { warnings->unimport('experimental::signatures') if eval "no warnings 'experimental::signatures'; 1"; }

    The advantage to this version is that it doesn't presume that the Perl version is a reliable indicator of whether or not some type of warning can be disabled. It is at least possible that some future version of something would mean that an upper bound on the version would need to be added. But I'm also not convinced that you can't have cases where unusual requirements lead to a mismatch between the Perl version and the behavior of "no warnings 'experimental::signatures';". For example, in building Perl for weird environments (like tiny Unix devices) I've ended up with versions of Perl where standard features got disabled because porting of base Perl got finished but not porting of some standard extensions for that version of Perl.

    - tye        

      Though, this approach also has the disadvantage of silently failing if your "no warnings" should be supported but something weird is just broken. You could mitigate that problem by emitting a warning (or fatal error) if the failure reason doesn't match the one expected, but that can lead to noise when your expectations become incorrect, of course.

      BEGIN { my $class = 'experimental::signatures'; if( eval "no warnings '$class'; 1" ) { warnings->unimport($class); } elsif( $@ !~ /Unknown warnings category / ) { warn "'no warnings' failed: $@\n"; # Or even die(). } }

      - tye        

      Hi tye,

      You're absolutely right that magic numbers are not good, that is a potential weakness of my proposed solutions.

      FWIW, when the postderef feature was taken out of experimental status, it was elected to leave the "experimental::postderef" warnings category in place but to make it a no-op. References: commit, P5P

      Regards,
      -- Hauke D

        FWIW, when the postderef feature was taken out of experimental status, it was elected to leave the "experimental::postderef" warnings category in place but to make it a no-op.

        As is good practice and as I would expect. But the next thing I would expect to eventually happen would be to clean out really old cruft by making references to 'experimental::postderef' deprecated and cause a warning and then to later make it fatal (by removing all mention of it from the source code). Not that I'll make any predictions about approximate time frames for such. :)

        - tye        

Re: Optionally / safely disabling a warning category for a complete package
by Corion (Patriarch) on May 19, 2016 at 18:43 UTC

    Thanks to everybody for their good and inspiring solutions!

    In the end (or rather, in release 0.03), I went with a different approach alltogether:

    When I install the source filter, I also install a fake warnings category experimental::signatures with it. This allows the code using Filter::signatures to also use no warnings 'experimental::signatures';, and more specifically, makes the switch between using the filter and removing all vestiges of this source filter a one-line change. CPAN testers will tell me how bad this idea was in the short run...