Bug #79550 for Modern-Perl: Make compile-time warnings fatal

Mon Sep 10 08:36:03 2012 EDAVIS [...] cpan.org - Ticket created

Subject:

Make compile-time warnings fatal

I'm enjoying using Modern::Perl and its automatic enabling of warnings and strict. One more thing to consider for a future version is to upgrade compile-time warnings to fatal errors: use warnings FATAL => 'syntax'; My understanding is that these are essentially syntax errors in the program, but to avoid breaking older code the parser defaults to whatever older versions of perl used to do, and emits a warning. Unlike run-time warnings, it is easy to find and fix all of these at once. If 'Modern Perl' exists as a dialect of Perl, it should exclude peculiar ambiguous constructs, even if for backwards compatibility the perl implementation will carry on with a warning.

Mon Sep 10 12:36:35 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Mon Sep 10 08:36:03 2012, EDAVIS wrote: Show quoted text

> I'm enjoying using Modern::Perl and its automatic enabling of warnings > and strict. One more thing to consider for a future version is to > upgrade compile-time warnings to fatal errors: > > use warnings FATAL => 'syntax'; > > My understanding is that these are essentially syntax errors in the > program, but to avoid breaking older code the parser defaults to > whatever older versions of perl used to do, and emits a warning. Unlike > run-time warnings, it is easy to find and fix all of these at once. > > If 'Modern Perl' exists as a dialect of Perl, it should exclude peculiar > ambiguous constructs, even if for backwards compatibility the perl > implementation will carry on with a warning.

Actually warnings are cases in which Perl guesses that you *might* be doing the wrong thing. Syntax warnings, in particular, are known to be buggy and generate false positives. See the following tickets: https://rt.perl.org/rt3/Ticket/Display.html?id=8979 https://rt.perl.org/rt3/Ticket/Display.html?id=28380 https://rt.perl.org/rt3/Ticket/Display.html?id=76910 https://rt.perl.org/rt3/Ticket/Display.html?id=77240 There is one other I can’t find right now.

Mon Sep 10 12:36:36 2012 The RT System itself - Status changed from 'new' to 'open'

Tue Sep 11 06:15:10 2012 EDAVIS [...] cpan.org - Correspondence added

Show quoted text

>Syntax warnings, in particular, are known to be buggy and generate >false positives.

I take your point. I was really thinking of the 'ambiguous' warnings, where I would prefer to write a more explicit dialect of Perl which avoids these constructs. Pragmatically, that is true even when the code isn't really ambiguous to an ideal parser but only because of limitations in the current implementation (as #8879). Note, however, that the false positive warning will still be there with or without Modern::Perl making it fatal. Most programmers try to make their code warnings-clean even when the warning is caused by a bug or limitation in the interpreter.

Tue Sep 11 12:42:05 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Tue Sep 11 06:15:10 2012, EDAVIS wrote: Show quoted text

> >Syntax warnings, in particular, are known to be buggy and generate > >false positives.

> > I take your point. I was really thinking of the 'ambiguous' warnings, > where I would prefer to write a more explicit dialect of Perl which avoids > these constructs. Pragmatically, that is true even when the code isn't > really ambiguous to an ideal parser but only because of limitations in the > current implementation (as #8879). > > Note, however, that the false positive warning will still be there with > or without Modern::Perl making it fatal. Most programmers try to make > their code warnings-clean even when the warning is caused by a bug or > limitation in the interpreter.

When warnings are wrong, I usually just turn them off. :-) BTW, I didn’t mean to imply that Modern::Perl should or shouldn’t make the change you suggested. I just wanted to make sure that such a decision is sufficiently informed, as this is a fairly widely used module.

Sun Jan 15 15:20:45 2017 chromatic [...] cpan.org - Correspondence added

If this is done, it won't be done retroactively. If it's ever done, it'll be because the rough community consensus in 2017 is, for example, "uninitialized value warnings should be fatal". I don't see that rough consensus right now, so I'm going to close this ticket that's lingered for too long and kick the can down the road a ways.

Sun Jan 15 15:20:50 2017 chromatic [...] cpan.org - Status changed from 'open' to 'rejected'