in reply to future warnings
I think use warnings (and the -w flag) should continue to enable all warnings. It might be reasonable to add a new warnings option to enable a restricted set of warnings, but that would involve tagging each possible warning with a severity as well as a class, and the reason we have warnings is usually because we don't know how severe the problem is: if we did, we either wouldn't emit a warning at all, or we'd die. (Consider, for example, what severity the "use of uninitialised value" should be.)
But, coming from the other side, I'm not convinced about the righteousness of "people [expecting] previously warnings-free code to stay that way when upgrading". For my own production code, if a new version of perl means my code emits a warning, that's a good thing - maybe there is a bug in my code I was never aware of, and if not it is usually little trouble to rework the code slightly to avoid the new warning. It is rare that a new warning isn't at least highlighting the fact that my code is doing something dubious, and I should be looking at it particularly carefully.
Again, if you know your code is perfect, why leave warnings enabled at all? Indeed, many people prefer to turn warnings off at the point code is put into production.
The real underlying problem, I think, is the granularity of the warnings pragma: almost always I want either all warnings, or all warnings except for this one. So I almost always have -w at the top of the script, and an occasional:
{ # add a block to minimise scope of fewer warnings no warnings qw/ thisone /; code that warns of thisone; }
As long as access to warnings is restricted to functional classes, this does almost exactly the wrong thing: I need to disable the one warning I know the code emits, and I'm happy that in this case that warning does not reflect an error in my code. However the one type of warning this code is likely to emit that would represent a genuine problem is any other warning from the thisone class. (This I think is one point Yves was trying to make in one of his recent p5p postings about sprintf.)
Perhaps, then, the right answer is for every warning to be tagged with an id, for an option to get the id shown when the warning is, and for the ability to lexically enable or disable individual warnings by id. However I am aware that this would involve a lot of work: as well as the effort involved in actually locating and tagging every current warning, the current implementation relies on propagating one bit for each specifiable class, and throwing around bitmasks with a bit for every conceivable warning would be unusably unwieldy.
Similarly, reimplementing with a chain of individually specified warnings (presumably, in most cases a chain representing "enable all warnings but these") would work fine except when supporting the existing practice, which means every no warnings qw/ foo / would need to construct a chain of as many warnings as exist in that foo class, a big cost to all the existing code out there.
I guess there must be some happy medium, which would allow efficient handling of both individual warnings and classes of warnings. And if such a medium can be implemented, I suspect that having introduced the ability to refer to individual warnings it should become much easier to specify new classes of warnings (such as "introduced in perl-5.8.3") that cut across the existing classes. And then we might have the best of all three worlds. :)
Hugo
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: future warnings
by TimToady (Parson) on Jul 09, 2004 at 21:32 UTC | |
Re^2: future warnings
by EvdB (Deacon) on Jul 09, 2004 at 10:18 UTC |