Perl warnings as in specific version?

Question

At the top of a Perl script, one can write use v5.14 and if the interpreter is older than that, it will exit with an error instead of trying (in vain) to execute a script that depends on features that don't exist yet. Further, this allows the addition of new features without breaking older scripts that expected to be able to use new keywords as identifiers. However, as far as I can tell, this does NOT prevent Perl from inventing new warnings, so code that ran without warnings in an old version will emit them in a new one. Is there a way to ask for "no new warnings please"? The context for this is admittedly silly: I want to use the smartmatch operator, which was retroactively declared experimental, and I don't want to type this ugly thing:

no if $] >= 5.017011, warnings => 'experimental::smartmatch'

EDIT: Footnote: I'm actually using FATAL => 'all', which admittedly has its own issues, but it guarantees that warnings get noticed. Luckily this is a user script (think grep or diff), so there is someone there to do something about it

1. Don't use smartmatch. 2. Configure your PERL5OPT (see [perlrun](http://p3rl.org/perlrun)). — choroba, Jul 26 '17 at 15:42
Re: smartmatch: are you saying smartmatch is bad, or are you saying it's not compatible with my goal of avoiding the ugly no-if-warnings line? — Mark VY, Jul 26 '17 at 15:46
It allows you to specify command line options, such as `-M`. That would only "help" for the main program file, though. — ikegami, Jul 26 '17 at 15:52
Are you suggesting that I pass the "no-if-warnings" things via the -M flag? — Mark VY, Jul 26 '17 at 16:01
That's where `choroba` was going with that, but most definitely "no!" — ikegami, Jul 26 '17 at 16:03

ikegami · Accepted Answer · 2017-07-26T16:05:13.187

2

I want to use the smartmatch operator

Don't! The design of smart-matching is broken, and it WILL be removed or changed in a backwards incompatible manner. See this.

Is there a way to ask for "no new warnings please"?

No. You can explicitly specify which categories of warnings you want to get, but that only stops new categories, not new warnings in existing categories.

Not actually what you asked, but you can filter warnings using a $SIG{__WARN__} hook. Of course, that's far more code than that one line.

I don't want to type this ugly thing

The following is sufficient if you use 5.18+:

no warnings qw( experimental::smartmatch );

If you might not have 5.18, then you could still simplify a tiny bit by using

no if $] >= 5.018, warnings => qw( experimental::smartmatch );

Using Import::Into, you could also create module that replaces the following boilerplate with just a simple use:

use strict;
use warnings;
use feature qw( switch );
no if $] >= 5.017011, warnings => qw( experimental::smartmatch );

edited Jul 26 '17 at 16:05

answered Jul 26 '17 at 15:51

ikegami

367,544
15
269
518

Okay, so it seems that the very smartmatch feature I was relying on is the one that's going away. I could just stick my head in the sand and assume that if it hasn't happened yet then it probably won't for a while, but even I'm not quite that foolhardy. I shall have to find another way to check if a value is contained in a list. Thank you! – Mark VY Jul 26 '17 at 16:21
1

`if ( grep { $_ eq 'target' } @a )` – ikegami Jul 26 '17 at 16:23
Not as pretty, but it will do. Thanks once more! – Mark VY Jul 26 '17 at 16:24
muh. If it's that ugly, move it into a sub. `if (inlist('target', @a))` – ikegami Jul 26 '17 at 16:25
Not so ugly that it's worth moving into a sub :) – Mark VY Jul 26 '17 at 16:25

score 0 · Answer 2 · answered Jul 26 '17 at 17:40

My unpopular opinion is that warnings are for development and testing but not production. Warnings that nobody sees aren't very useful.

You can turn off warnings:

no warnings;

And you can turn off types of warnings:

no warnings qw(void);

My advice only works if you're doing the smart thing of creating a test suite and using that to check your upgrade before you deploy it. If you're upgrading and hoping for the best, this doesn't really work for you because warnings aren't the biggest problem you might face. I'd be more worried about subtle behavior changes and module upgrades.

If you aren't testing before you deploy, watch the logs for a few days. When you see the warnings that you aren't going to fix, you can disable them. But that means you are logging stuff, which I also notice people tend not to do. :)

I'm actually using FATAL => 'all', which admittedly has its own issues, but you'll admit that it guarantees that warnings get noticed. Luckily this is a user script (think grep or diff), so there is someone there to do something about it. — Mark VY, Jul 26 '17 at 17:48

Perl warnings as in specific version?

2 Answers2