Front page | perl.perl6.language.strict |
Postings from February 2001
schwern@pobox.com wrote: > > But we can run an experiment. Warnings can be made default for the > first few releases of Perl 6 and we'll see what happens. If it looks > good, leave them on. If not, shut them off. Unlike most other > features, this one doesn't have any serious backwards compatibility > consequences! Ummm, I'm not too sure about this. There are, actually, backwards compatibility concerns. Unless I'm mistaken, warnings go to stderr, correct? Meaning that a program which may have lots of "unitialized variables" and "variable only used once" warnings in them, *and* which rely on outputting useful information to stderr (like "real" warnings that the user put in the program) will have that polluted with lots of Perl gunk. This doesn't break code, but it does break the usability and behavior of the program. So to do this effectively and transparently p52p6 should really stick a "no warnings" in a p5 script to make sure that stderr isn't polluted. But then we're back to where we are now.... Maybe what we really should be talking about is a way to let site users customize what flags are on by default? Just like customizing which modules are dynamically vs. statically loaded. I know this issue got beaten to death in the language RFC process already, but... if there are truly 2 groups with opposing viewpoints, why not add to Configure: Command-line flags on by default [-T -Mstrict -Mwarnings]: ?????? -Nate