Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Oct 7, 2019 · 14 comments · Fixed by #18666
Closed

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

p5pRT opened this issue Oct 7, 2019 · 14 comments · Fixed by #18666

Comments

@p5pRT
Copy link

p5pRT commented Oct 7, 2019

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

Searchable as RT134484$

@p5pRT
Copy link
Author

p5pRT commented Oct 7, 2019

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
Copy link
Author

p5pRT commented Oct 7, 2019

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
Copy link
Author

p5pRT commented Oct 7, 2019

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

@p5pRT
Copy link
Author

p5pRT commented Oct 7, 2019

From @Grinnz

On Mon, Oct 7, 2019 at 5​:04 PM Ryan Voots <simcop2387@​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
Copy link
Author

p5pRT commented Oct 7, 2019

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
Copy link
Author

p5pRT commented Oct 14, 2019

From @pali

Any comments from perl maintainers?

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

@p5pRT
Copy link
Author

p5pRT commented Oct 14, 2019

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
Copy link
Author

p5pRT commented Oct 14, 2019

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
Copy link
Author

p5pRT commented Oct 15, 2019

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
Copy link
Author

p5pRT commented Oct 15, 2019

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
Copy link
Author

p5pRT commented Oct 16, 2019

From wagnerc@plebeian.com

I would not like to see warnings enabled by default with any use <version> 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
Copy link
Author

p5pRT commented Oct 16, 2019

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
Copy link
Contributor

leonerd commented Jul 3, 2020

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
Copy link
Contributor

leonerd commented Mar 22, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants