Front page | perl.perl5.porters |
Postings from July 2014
On Mon, Jun 23, 2014 at 01:23:35AM +0200, Aristotle Pagaltzis wrote: > * Ævar Arnfjörð Bjarmason <avarab@gmail.com> [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 > > http://perl5.git.perl.org/perl.git/log/refs/heads/smoke-me/avar/warn-grep-void-ctx > > > > These warnings are still turned on by -W on the command-line, and > > I haven't yet updated any of the warnings.pm 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. AbigailThread Previous | Thread Next