Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

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 specificiable 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. :)


In reply to Re: future warnings by hv
in thread future warnings by ysth

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others musing on the Monastery: (6)
    As of 2018-06-20 12:26 GMT
    Find Nodes?
      Voting Booth?
      Should cpanminus be part of the standard Perl release?

      Results (116 votes). Check out past polls.