Whilst warnings do tend to follow the data; doesn't their significance (benign or actionable) depend upon the purpose/function of the code manipulating that data?
Either that, or the purpose of the code creating that data.
Enabling or disabling some warnings at some localized scope can certainly be useful. The short-comings of warnings.pm are only partial.
You could repair some of the shortcomings of warnings.pm by allowing subs to declare that they want string values or numeric values (well, for positional arguments), such that the conversion from scalar to string/number would happen in the context of the call to the sub rather than inside the sub when the arguments are extracted or even later when they are finally put to real use.
You could also repair them by providing a way for a sub to request code to be run with the caller's warnings settings. Then a careful module author could go to the effort to "cast" any provided values to the more-specific type in a way that would only cause a warning if the caller wanted to hear that type of warning.
sub careful {
my( $string, $number ) = @_;
{
use warnings ':caller';
$string = "$string";
$number = 0+$number;
}
...
}
You could also put the onus on the author of the calling code. This doesn't make much sense to me in the case of the caller not wanting warnings, but I can see it making sense when the caller wants warnings but the called sub doesn't have warnings enabled:
use warnings;
...
sloppy( "$string", 0+$number );
These relatively few data-specific warnings might be rather insignificant if it weren't for the fact that "uninitialized" warnings are probably the single most common warning both in terms of how likely they are to happen and in how often people want to ignore them.
Though, I'm not advocating for such feature enhancements to Perl. I'm happy with my "-w" and (newly adopted) "-X".
|