On 2010-06-18, at 10:48 am, Larry Wall wrote: > If you make it the default to not warn, then the people who really need the > warnings will almost never turn them on. If you make it default to warn, > then people will have to turn off the warnings forever.
Doesn't the site-policy policy help here? I could turn certain warnings off in my policy file instead of having to turn them off in every new program. Of course, such settings should arguably apply per-project or per-person-who-wrote-the-code; so maybe any file should adopt settings from a .policy.pm in its own dir, if there is one. Actually, no, it should probably "use Some::Policy", but there should be a way for a policy module to identify itself as such so Perl knows whether it should override or be overridden by other policy modules. Also, certain warnings could be suppressed if the code is compiled, on the grounds that compiling the code is a way of saying, "I'm finished with this, it all works and I don't expect to be changing it any more". Library modules will presumably be compiled, so that would prevent warnings from code you didn't even write. (Although if a module you installed from somewhere else is full of warnings, maybe you do want to know, hm....) > 0123; # warns > 0123; # ok! # suppresses this warning here > 0123; # OK! # suppresses this warning from now on > > Though I'm hesitant to use comment syntax for that. A statement prefix might > be more appropriate. We've currently reserved "quietly" for simple run-time > warning suppression, but that's kinda long, and not defined for compile-time > warnings yet. Admittedly, it would be rather amusing to have to shout at > Perl 6 to make it shut up: > my $x = QUIETLY 0123; Call it "sh"? (for "suppression handler", of course) Using comments doesn't feel quite right to me either, but on the other hand, almost anything else seems distracting for something that is supposed to avoid drawing attention. Maybe a statement suffix? -David
