Front page | perl.perl5.porters |
Postings from October 2015
* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2015-10-19 04:40]: > If we admit that we may want new warnings to be available, but not > turned on by "use warnings;", and that they can only be added to the > core, then it is going to be the case that the user will need to add > something to request them. This strategy just avoids the needless > multiplication of interfaces to do that. Sure, such as using Perl::Critic on their code. And obviously there is runtime stuff that Perl::Critic cannot catch, that it would be nice to be able to catch via some mechanism. That is the requirement, and it is a reasonable one. Implementing those checks as warnings, which `use warnings` does not enable, is *a* solution for this requirement, but not the only possible one, and I remain unconvinced it is even a good one, let alone the best (or something in the ballpark). I really don’t feel comfortable with the “well it seems reasonable, and Ævar really wants it (by reasoning from a bad analogy with C compilers), so let’s proceed” approach. That’s how we got autoderef, except this one would be far harder to excise if it turns out to be a mistake; more like v-strings, a regret to live with forever after. Can we somehow make this an experimental feature? I am willing to have my mind changed by an absence of problems in practice, but would prefer if everyone else also received an opportunity to have their mind changed by the presence of problems in practice. (Of course there is also the problem that once this makes it out to the real world, it will incur breakage – and a potentially terrible amount thereof. That would be a huge waste of goodwill if the feature turns out to be regrettable. So the initial incarnation in blead would probably have to be non-experimental, and CPAN-smoked, to get an idea of how much terror to expect.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next