search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.9k stars 540 forks source link

Proposal for enabling warnings with 'use v5.32' #17162

Closed p5pRT closed 3 years ago

p5pRT commented 4 years ago

Migrated from rt.perl.org#134484 (status was 'open')

Searchable as RT134484$

p5pRT commented 4 years ago

From @pali

Specifying 'use v5.12' or higher automatically calls 'use strict'. When writing new Perl code it is also recommended to enable also warnings via 'use warnings'.

So what about automatically enabling also warnings when 'use v5.32' (or higher) is specified? Similarly like strictures are enabled with v5.12+.

p5pRT commented 4 years ago

From @simcop2387

I think the main concern with doing this would be that strict and the other enabled feature bundles are things that happen or error at compile time\, so they'll bail out early if misused or missing. With warnings most of them happen during run time (all? not sure). So that'd be something that differs considerably compared to how strict and the other features work at least. Since it'd be something in the version bundle though\, I don't think it could impact existing scripts or programs since it'll only take effect on code that's being newly written or updated so there's not really a chance that it'll cause extraneous output that breaks some existing code. At least that's my understanding of everything that gets changed when using a perl version bundle like that.

Ryan Voots

On Mon\, Oct 7\, 2019 at 5​:36 AM (via RT) \perlbug\-followup@​perl\.org wrote​:

# New Ticket Created by # Please include the string​: [perl #134484] # in the subject line of all future correspondence about this issue. # \<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=134484 >

Specifying 'use v5.12' or higher automatically calls 'use strict'. When writing new Perl code it is also recommended to enable also warnings via 'use warnings'.

So what about automatically enabling also warnings when 'use v5.32' (or higher) is specified? Similarly like strictures are enabled with v5.12+.

p5pRT commented 4 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 4 years ago

From @grinnz

On Mon\, Oct 7\, 2019 at 5​:04 PM Ryan Voots \simcop2387@&#8203;simcop2387\.info wrote​:

I think the main concern with doing this would be that strict and the other enabled feature bundles are things that happen or error at compile time\, so they'll bail out early if misused or missing. With warnings most of them happen during run time (all? not sure). So that'd be something that differs considerably compared to how strict and the other features work at least. Since it'd be something in the version bundle though\, I don't think it could impact existing scripts or programs since it'll only take effect on code that's being newly written or updated so there's not really a chance that it'll cause extraneous output that breaks some existing code. At least that's my understanding of everything that gets changed when using a perl version bundle like that.

(Resent to list)

I don't think that's a relevant concern. Some aspects of strict are runtime\, as are new features added to feature bundles. The difference would be that default warnings change from version to version\, and this is part of the warnings contract\, and rarely happens with features (one example being unicode_strings gaining additional functionality).

-Dan

p5pRT commented 4 years ago

From @pali

On Monday 07 October 2019 14​:04​:45 Ryan Voots via RT wrote​:

I think the main concern with doing this would be that strict and the other enabled feature bundles are things that happen or error at compile time\, so they'll bail out early if misused or missing. With warnings most of them happen during run time (all? not sure).

No\, some warnings are compile time and some warnings are runtime. Even before warnings.pm appeared it was suggested to put $^W = 1 into BEGIN block so perl throw also compile time warnings and not only runtime.

Example of compile time warning​: $ perl -w -e 'print "begin\n"; sub a {} sub a {}' Subroutine a redefined at -e line 1. begin

So that'd be something that differs considerably compared to how strict and the other features work at least. Since it'd be something in the version bundle though\, I don't think it could impact existing scripts or programs since it'll only take effect on code that's being newly written or updated so there's not really a chance that it'll cause extraneous output that breaks some existing code.

Exactly. My proposed suggestion is backward compatible. It does not change behavior of currently written code so it should not break existing code.

At least that's my understanding of everything that gets changed when using a perl version bundle like that.

Ryan Voots

p5pRT commented 4 years ago

From @pali

Any comments from perl maintainers?

Is this proposed change a good idea which could be integrated into Perl 5.32?

p5pRT commented 4 years ago

From @jkeenan

On Mon\, 14 Oct 2019 10​:57​:01 GMT\, pali@​cpan.org wrote​:

Any comments from perl maintainers?

Is this proposed change a good idea which could be integrated into Perl 5.32?

I don't see a compelling argument for this. Simply saying that we should do something similar to what we did 10 years ago is not enough of a rationale. Nor do I see a groundswell of support for it.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

p5pRT commented 4 years ago

From @karenetheridge

On Mon\, 14 Oct 2019 04​:03​:40 -0700\, jkeenan wrote​:

I don't see a compelling argument for this. Simply saying that we should do something similar to what we did 10 years ago is not enough of a rationale. Nor do I see a groundswell of support for it.

We're constantly reminding beginners to include 'use strict; use warnings;' at the top of every file\, and we always reflexively add it ourselves\, so is there a technical reason why we *shouldn't* add it to the 5.32 pragma? after all\, it will only come into effect in new code (that can only run on 5.32 or later) so there is no worry about breaking old code\, or surprising effects in cpan modules etc.

p5pRT commented 4 years ago

From @iabyn

On Mon\, Oct 14\, 2019 at 04​:48​:12PM -0700\, Karen Etheridge via RT wrote​:

On Mon\, 14 Oct 2019 04​:03​:40 -0700\, jkeenan wrote​:

I don't see a compelling argument for this. Simply saying that we should do something similar to what we did 10 years ago is not enough of a rationale. Nor do I see a groundswell of support for it.

We're constantly reminding beginners to include 'use strict; use warnings;' at the top of every file\, and we always reflexively add it ourselves\, so is there a technical reason why we *shouldn't* add it to the 5.32 pragma? after all\, it will only come into effect in new code (that can only run on 5.32 or later) so there is no worry about breaking old code\, or surprising effects in cpan modules etc.

But code can break on later versions of perl when new warnings are added. If you add 'use warnings' at the top of your code you are explicitly accepting this risk. Adding something like 'use 5.32.0' is one step removed\, and given how much abuse we regularly receive from some quarters that we have "broken perl" when we add a new warning I don't want to give them any more ammo.

-- "Do not dabble in paradox\, Edward\, it puts you in danger of fortuitous wit."   -- Lady Croom\, "Arcadia"

p5pRT commented 4 years ago

From @dur-randir

On Tue\, 15 Oct 2019 03​:13​:55 -0700\, davem wrote​:

But code can break on later versions of perl when new warnings are added.

Can we than freeze 'use v5.xx'\, xx >= 32 to enable the exact warnings set that was in the xx version\, and not 'warnings all' set?

p5pRT commented 4 years ago

From wagnerc@plebeian.com

I would not like to see warnings enabled by default with any use \ statement. It would simply create new boilerplate for me and many others​: "no warnings" in every script. Occasionally I do use warnings in development to make sure I haven't done something bonkers but then disable it. And frankly\, many of the default warnings are pedantic.

Thanks.

p5pRT commented 4 years ago

From @pali

On Monday 14 October 2019 16​:48​:12 Karen Etheridge via RT wrote​:

On Mon\, 14 Oct 2019 04​:03​:40 -0700\, jkeenan wrote​:

I don't see a compelling argument for this. Simply saying that we should do something similar to what we did 10 years ago is not enough of a rationale. Nor do I see a groundswell of support for it.

We're constantly reminding beginners to include 'use strict; use warnings;' at the top of every file\, and we always reflexively add it ourselves\, so is there a technical reason why we *shouldn't* add it to the 5.32 pragma? after all\, it will only come into effect in new code (that can only run on 5.32 or later) so there is no worry about breaking old code\, or surprising effects in cpan modules etc.

That is the reason why I proposed this change and opened discussion for it. If there is a problem that 'all warnings' may be changed in the future we can also not enable 'all warnings'\, but just specify list of warnings which are available in that release.

leonerd commented 4 years ago

Under the current proposal to have a new perl 7 that defaults to turning on warnings even without an explicit use VERSION declaration, I think this feature request deserves another look.

leonerd commented 3 years ago

The "Perl 7" plan has been raised once again. I really think we should look into this a second time.

https://www.nntp.perl.org/group/perl.perl5.porters/2021/03/msg259374.html