http://www.perlmonks.org?node_id=373029


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
    Why limit yourself to three worlds? Perhaps warnings should be considered to be like some kind of row in a relational table, and you can apply any selection criterion on any attribute of the data. Or consider a warning to be an object that decides whether or not to say anything based on the selection criteria it can see in its various outward lexical scopes. The actual selection criteria do not need to be physically replicated as long as you can follow the chain of criteria outward somehow. Bitmasks are merely a useful optimization for certain selection criteria.
Re^2: future warnings
by EvdB (Deacon) on Jul 09, 2004 at 10:18 UTC
    I agree that all warnings should be enabled by default, even if this means that previously warning free code starts to complain.

    I would think of these new warnings as a free bit of peer review, rather than annoying. After all if there is a problem with production code I want it to be mentioned.

    If the code was warning free and you don't want new warnings then switch off warnings. You can switch it back on if you make changes in which case you are in a good position to address the new warnings.

    --tidiness is the memory loss of environmental mnemonics