[EMAIL PROTECTED] 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
