develooper Front page | perl.perl5.porters | Postings from July 2014

Re: RFC: Support for new warning categories outside of "all"

Thread Previous | Thread Next
July 1, 2014 07:17
Re: RFC: Support for new warning categories outside of "all"
Message ID:
On Mon, Jun 23, 2014 at 01:23:35AM +0200, Aristotle Pagaltzis wrote:
> * Ævar Arnfjörð Bjarmason <> [2014-06-22 11:45]:
> > I've just pushed smoke-me/avar/warn-grep-void-ctx which adds support
> > for adding new warnings that aren't enabled by "use warnings", but
> > rather by e.g. "use warnings qw(pedantic)". See
> >
> >
> > These warnings are still turned on by -W on the command-line, and
> > I haven't yet updated any of the docs to be less confusing
> > in the face of this change.
> >
> > But this I think is a viable way forward to bring controversial
> > warnings into the core without making it a pain to run existing code
> > on new perl versions. To that end the patch brings back a warning that
> > was removed from blead already over objections about it not belonging
> > in the default set of warnings.
> >
> > Hopefully it and other similar warnings will cause no such objections
> > when authors have to explicitly opt-in to view them.
> This does not seem sustainable to me. It just makes
>     use warnings qw( all pedantic );
> the new
>     use warnings;
> After your change, someone who wants all warnings would have to start
> scripts with the former rather than the latter, as was the case so far.
> So then there is a bunch of scripts that enable all+pedantic.
> Now you release a new perl that adds warnings to the pedantic category…
> … and you get exactly the same problem you had before: you cannot add
> more warnings to the “pedantic” category without causing heartburn to
> the same kind of people who got heartburn from new warnings before.
> The only way to solve the issue long-term is to version-tag all warnings
> and then use that information to give users a way to say “enable all the
> warnings that existed as of 5.20, but none that were added later”. Or as
> of 5.22. Etc. Then users can ask for a known, fixed set of warnings that
> will not change from under them. (Or not a fixed set, actually: removing
> warnings from it should be fine. Just not adding any.)

But that's not the contention.

The majority of new warnings are for new constructs. The problem is *new*
warnings for *existing* constructs.

If I write something in the 5.20 era, and in 5.22 a new construct is added
which comes with its own warnings, I like those warnings to be enabled --
after all, I may modify my program and use a 5.22 construct.

But if 5.22 suddenly starts to warn on ^ (just because someone once used ^
instead of **, and now thinks ^ should warn), or if p5p suddenly decides
'say' is experimental, I don't think those are warnings that should be
enabled by default.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About