On 6/23/14, 7:32 AM, George Greer wrote:
On Sun, 22 Jun 2014, Eric Brine wrote:

p5p has been arguing that adding new warnings is not a backwards
compatibility break because people using C<< use warnings; >> are
to be warned of problems even if they aren't currently classified as
problems. If that's true, then C<< use warnings; >> no longer does what
people expect it to do, so you must believe that what Aevar is requesting
breaks backwards compatibility.
Ævar CC'd me on this. I don't have the recent context, but this seems
like an old, old p5p argument. Here is my $0.02.

Once you have "all warnings" and "more all warnings" you'll want "more
more all warnings" and "other more all warnings" and it will rapidly
explode until we're gcc. It will be very tempting to shove more and
more warnings into special categories which are not "all". This is a
slippery slope argument, which isn't terribly convincing because we're
not new to this language design game and can show some restraint, but it
cannot be ignored.

Here's a better reason.

Warnings are things which are *probably* a mistake, but not definitely a
mistake. If they were definitely a mistake, they'd be an error. In
this light, splitting between "all, but not really all, warnings" and
"really all warnings" is a mistake. ALL warnings are already judgement

OTOH there really are some warnings which are quite annoying and
pedantic and often wrong. It would be nice if there were a way to turn
them off. The key here is turn them *OFF*. Not turn them on.

Why turn them off? If these warnings are important enough that we feel
they should be in the core, rather than in Perl::Critic or something,
then it's important the programmer makes a conscious decision about
whether or not the warning applies to their code.

Warnings you have to turn on don't get turned on, not without years and
years of training the community. If it's not a feature they need to get
their job done, they're not going to seek it out to turn it on. People
can't make good decisions about warnings they never see and are never
aware of (no, you can't count on people reading perldelta).

For that reason "use warnings" should remain *all warnings* even the
pedantic ones. If they're too pedantic, they're not useful warnings and
should be removed and moved to Perl::Critic.

To be pragmatic, there should be an easy way to select a less pedantic
set of warnings. "use warnings ':relaxed'" or something. The important
thing is this is a conscious, visible decision on the part of the person
writing the code. They saw the warnings, and they decided to turn them off.

As for backwards compatibility, this problem with adding warnings
happens in EVERY version of Perl. If your code is so fragile that it
will freak out at new warnings, you're already doomed. But there's a
forward solution to that below.

The idea is that people who care would do:

# All warnings as of v5.20, even if using a newer perl binary.
use warnings ":5.20";

Questions would be:

- What does asking for ":5.20" do with a (for example) 5.18.x perl binary?
The same thing "use v5.20" does, it throws an exception. 5.18 cannot
give you that feature, asking for it is an error. 5.18 already does this.

$ perl -wle 'use warnings ":5.20"'
Unknown warnings category ':5.20' at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

- If a warning was later removed, should asking for an older version's
warnings bring it back?
Following the "use v5.x" model, yes.

The last question reflects the effort of how far on the spectrum of
backward-compatibility do you want to go? How far is worth it? How far
does anyone actually need it to be? How far do we consider reasonable?
How far until "if you want it, you need to contribute time/money
yourself" to get it?
These are all the same questions as the "use v5.x" semantics raised and
they should be answered the same way. Compared to maintaining old
features per version, maintaining old warnings is cake.

Here is a solution going forward.

If we're going to add version specific warnings categories, they should
be implicitly turned on by a "use v5.x" line. For example...

     use v5.22;
     use warnings;


     use warnings ':5.22';

Should be functionally equivalent wrt warnings. This avoids having to
declare the version of Perl the code was written to multiples times.

This handily solves the problem of new warnings messing up old code,
same as "use v5.x" solves the problem of new features messing up old code.

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase