Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Perl>
  3. porters
use strict/warnings version bundles
leonerd at leonerd
Jan 30, 2023, 3:13 AM
Post #1 of 14 (321 views)
Permalink
We've had various thoughts and ideas in the past about adding new
strictness or warnings flags, but often they get tripped up on the
meaning of

use strict;

to be a shortcut for "use strict ':all'" and people dislike adding a
new thing that isn't all.

I would like us to get out of this problematic logjam.

To that end, I would like to propose that strict.pm and warnings.pm
should recognise the same version bundle syntax that feature.pm already
does, and builtin.pm will do once anything about it becomes
non-experimental. In that way, it would be neat to explain and
remember, that e.g.

use v5.40;

is really a shortcut for

use strict ':5.40';
use warnings ':5.40';
use feature ':5.40';
use builtin ':5.40';

Currently I am not proposing any actual bundle changes to either of
these modules. Both modules would do the same as they do now, when
given any bundle number between :5.6 and :5.38 (the new "stable"
version as it will be). It's simply to carve out the syntax space for
permitting it in future, as currently they fail:

$ perl
use strict ':5.32';
Unknown 'strict' tag(s) ':5.32' at - line 1.
BEGIN failed--compilation aborted at - line 1.


Once they do support those numbered version bundles, then it would
become quite a lot simpler in future to add some new strictness or
default-on warning flag, which is dependent on that version number.

How do we feel?

* Just do it?
* Write up a full RFC?
* No way because ...?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: use strict/warnings version bundles [ In reply to ]
demerphq at gmail
Jan 30, 2023, 5:58 AM
Post #2 of 14 (321 views)
Permalink
On Mon, 30 Jan 2023, 19:13 Paul "LeoNerd" Evans, <leonerd@leonerd.org.uk>
wrote:

> We've had various thoughts and ideas in the past about adding new
> strictness or warnings flags, but often they get tripped up on the
> meaning of
>
> use strict;
>
> to be a shortcut for "use strict ':all'" and people dislike adding a
> new thing that isn't all.
>
> I would like us to get out of this problematic logjam.
>
> To that end, I would like to propose that strict.pm and warnings.pm
> should recognise the same version bundle syntax that feature.pm already
> does, and builtin.pm will do once anything about it becomes
> non-experimental. In that way, it would be neat to explain and
> remember, that e.g.
>
> use v5.40;
>
> is really a shortcut for
>
> use strict ':5.40';
> use warnings ':5.40';
> use feature ':5.40';
> use builtin ':5.40';
>
> Currently I am not proposing any actual bundle changes to either of
> these modules. Both modules would do the same as they do now, when
> given any bundle number between :5.6 and :5.38 (the new "stable"
> version as it will be). It's simply to carve out the syntax space for
> permitting it in future, as currently they fail:
>
> $ perl
> use strict ':5.32';
> Unknown 'strict' tag(s) ':5.32' at - line 1.
> BEGIN failed--compilation aborted at - line 1.
>
>
> Once they do support those numbered version bundles, then it would
> become quite a lot simpler in future to add some new strictness or
> default-on warning flag, which is dependent on that version number.
>
> How do we feel?
>
> * Just do it?
>

+1

Best proposal I've seen for this so far. In hindsight it's a bit surprising
nobody suggested this already. Good on you for suggesting it.

Cheers
Yves

>
Re: use strict/warnings version bundles [ In reply to ]
perl5-porters at perl
Jan 30, 2023, 7:05 AM
Post #3 of 14 (321 views)
Permalink
Hi there,

On Mon, 30 Jan 2023, Paul "LeoNerd" Evans wrote:

> ... I would like to propose that strict.pm and warnings.pm
> should recognise the same version bundle syntax that feature.pm already
> does...
> ...
> ...
> How do we feel?
> ...

Well it seems like a reasonable proposal, but I have to say that I'd
feel very much happier about things like this if Perl could just print
the right line number in the source file in warnings, which apparently
it hasn't been able to do reliably for more than a decade:

https://github.com/Perl/perl5/issues/12573

To get around this I'm currently writing some code roughly like this:

sub my_print_log_message
{
printf( shift, ' at line=%d\n', (caller(1))[2]);
}

if( $condition )
{
my $perl_cant_count = 1; // unused scalar
my_print_log_message( 'junk' );
}

but it's *really* tedious. Without the unused scalar the line number
that gets printed is often wrong. Sometimes it's the line number of
the conditional so maybe only out by a small number, but occasionally
I've seen it wrong by up to about 20 lines and, even if it's only out
by two, with "if-elsif-elsif-else" things can quickly get confusing.

If anybody knows a better way to get reliable line numbers in my log
messages please chime in. I don't (at least I don't knowingly) use
the '# line', er, feature *anywhere* ("Plain Old Comments (Not!)").

See issue 12573 for Perl version information here.

--

73,
Ged.
Re: use strict/warnings version bundles [ In reply to ]
ilmari at ilmari
Jan 30, 2023, 7:26 AM
Post #4 of 14 (321 views)
Permalink
"G.W. Haywood" via perl5-porters <perl5-porters@perl.org> writes:

> Hi there,
>
> On Mon, 30 Jan 2023, Paul "LeoNerd" Evans wrote:
>
>> ... I would like to propose that strict.pm and warnings.pm
>> should recognise the same version bundle syntax that feature.pm already
>> does...
>> ...
>> ...
>> How do we feel?
>> ...
>
> Well it seems like a reasonable proposal, but I have to say that I'd
> feel very much happier about things like this if Perl could just print
> the right line number in the source file in warnings, which apparently
> it hasn't been able to do reliably for more than a decade:
>
> https://github.com/Perl/perl5/issues/12573

That has nothing to do with this proposal. Please stick to the topic at
hand and don't derail the thread with your unrelated pet peeves.

- ilmari
Re: use strict/warnings version bundles [ In reply to ]
grinnz at gmail
Jan 30, 2023, 7:55 AM
Post #5 of 14 (321 views)
Permalink
On Mon, Jan 30, 2023 at 6:13 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> We've had various thoughts and ideas in the past about adding new
> strictness or warnings flags, but often they get tripped up on the
> meaning of
>
> use strict;
>
> to be a shortcut for "use strict ':all'" and people dislike adding a
> new thing that isn't all.
>
> I would like us to get out of this problematic logjam.
>
> To that end, I would like to propose that strict.pm and warnings.pm
> should recognise the same version bundle syntax that feature.pm already
> does, and builtin.pm will do once anything about it becomes
> non-experimental. In that way, it would be neat to explain and
> remember, that e.g.
>
> use v5.40;
>
> is really a shortcut for
>
> use strict ':5.40';
> use warnings ':5.40';
> use feature ':5.40';
> use builtin ':5.40';
>
> Currently I am not proposing any actual bundle changes to either of
> these modules. Both modules would do the same as they do now, when
> given any bundle number between :5.6 and :5.38 (the new "stable"
> version as it will be). It's simply to carve out the syntax space for
> permitting it in future, as currently they fail:
>
> $ perl
> use strict ':5.32';
> Unknown 'strict' tag(s) ':5.32' at - line 1.
> BEGIN failed--compilation aborted at - line 1.
>
>
> Once they do support those numbered version bundles, then it would
> become quite a lot simpler in future to add some new strictness or
> default-on warning flag, which is dependent on that version number.
>
> How do we feel?
>
> * Just do it?
> * Write up a full RFC?
> * No way because ...?
>

As I have mentioned in the past, I think this is reasonable for strict, but
not for warnings. Warnings are meant to be added and modified freely in
each version without requiring users to opt in to new behavior, and users
expect to receive new warnings reasonable to the categories/levels they
have opted into when upgrading Perl without having to change their code.

-Dan
Re: use strict/warnings version bundles [ In reply to ]
grinnz at gmail
Jan 30, 2023, 7:57 AM
Post #6 of 14 (321 views)
Permalink
On Mon, Jan 30, 2023 at 10:55 AM Dan Book <grinnz@gmail.com> wrote:

>
> As I have mentioned in the past, I think this is reasonable for strict,
> but not for warnings. Warnings are meant to be added and modified freely in
> each version without requiring users to opt in to new behavior, and users
> expect to receive new warnings reasonable to the categories/levels they
> have opted into when upgrading Perl without having to change their code.
>

(in fact, because of default and severe warnings, this will
happen regardless of what we do with warnings.pm.)

-Dan
Re: use strict/warnings version bundles [ In reply to ]
perl5-porters at perl
Jan 30, 2023, 8:05 AM
Post #7 of 14 (321 views)
Permalink
Hi there,

On Mon, 30 Jan 2023, Dagfinn Ilmari Manns?ker wrote:
> "G.W. Haywood" via perl5-porters <perl5-porters@perl.org> writes:
>> On Mon, 30 Jan 2023, Paul "LeoNerd" Evans wrote:
>>
>>> ... I would like to propose that strict.pm and warnings.pm
>>> should recognise the same version bundle syntax that feature.pm already
>>> does...
>>> ...
>>
>> Well it seems like a reasonable proposal, but I have to say that I'd
>> feel very much happier about things like this if Perl could just print
>> the right line number in the source file in warnings, which apparently
>> it hasn't been able to do reliably for more than a decade:
>>
>> https://github.com/Perl/perl5/issues/12573
>
> That has nothing to do with this proposal. Please stick to the topic at
> hand and don't derail the thread with your unrelated pet peeves.

I beg to differ.

This is about warnings. The proposal is to add yet more complexity at
the risk of still more issues when the warnings can't be trusted to do
the simplest thing - show the relevant line number - correctly.

I'd propose that Perl's warnings learn to walk before they try to run.

--

73,
Ged.
Re: use strict/warnings version bundles [ In reply to ]
ilmari at ilmari
Jan 30, 2023, 8:19 AM
Post #8 of 14 (321 views)
Permalink
"G.W. Haywood" via perl5-porters <perl5-porters@perl.org> writes:

> Hi there,
>
> On Mon, 30 Jan 2023, Dagfinn Ilmari Mannsåker wrote:
>> "G.W. Haywood" via perl5-porters <perl5-porters@perl.org> writes:
>>> On Mon, 30 Jan 2023, Paul "LeoNerd" Evans wrote:
>>>
>>>> ... I would like to propose that strict.pm and warnings.pm
>>>> should recognise the same version bundle syntax that feature.pm already
>>>> does...
>>>> ...
>>>
>>> Well it seems like a reasonable proposal, but I have to say that I'd
>>> feel very much happier about things like this if Perl could just print
>>> the right line number in the source file in warnings, which apparently
>>> it hasn't been able to do reliably for more than a decade:
>>>
>>> https://github.com/Perl/perl5/issues/12573
>> That has nothing to do with this proposal. Please stick to the topic
>> at
>> hand and don't derail the thread with your unrelated pet peeves.
>
> I beg to differ.
>
> This is about warnings.

This proposal is about determining which warnings are enabled in a given
scope (for which perl already has all the required infrastructure, this
is just creating another dimension of the existing warning categories).

> The proposal is to add yet more complexity at
> the risk of still more issues when the warnings can't be trusted to do
> the simplest thing - show the relevant line number - correctly.

Your complaint is about how the line is determined once the warning is
being shown. These two aspects are orthogonal.

> I'd propose that Perl's warnings learn to walk before they try to run.

No, you're complaining that Perl's warnings are being taught to talk
before they can walk. Yes, they should do both, but doing one doesn't
preclude doing the other.

Feel free to contribute towards fixing one of the issues, but please
don't derail the people wanting to fix the other one.

- ilmari
Re: use strict/warnings version bundles [ In reply to ]
davem at iabyn
Jan 30, 2023, 8:29 AM
Post #9 of 14 (321 views)
Permalink
On Mon, Jan 30, 2023 at 04:05:30PM +0000, G.W. Haywood via perl5-porters wrote:
> I beg to differ.
>
> This is about warnings. The proposal is to add yet more complexity at
> the risk of still more issues when the warnings can't be trusted to do
> the simplest thing - show the relevant line number - correctly.
>
> I'd propose that Perl's warnings learn to walk before they try to run.

They are two separate issues which attempt to solve two separate bugs,
which can (in theory) be solved by two different kinds of people working
independent of each other.

Open a new ticket or thread if you like, but please don't discuss it
further in this thread.


--
Little fly, thy summer's play my thoughtless hand
has terminated with extreme prejudice.
(with apologies to William Blake)
Re: use strict/warnings version bundles [ In reply to ]
fawaka at gmail
Jan 30, 2023, 8:32 AM
Post #10 of 14 (321 views)
Permalink
On Mon, Jan 30, 2023 at 4:55 PM Dan Book <grinnz@gmail.com> wrote:

> On Mon, Jan 30, 2023 at 6:13 AM Paul "LeoNerd" Evans <
> leonerd@leonerd.org.uk> wrote:
>
>> We've had various thoughts and ideas in the past about adding new
>> strictness or warnings flags, but often they get tripped up on the
>> meaning of
>>
>> use strict;
>>
>> to be a shortcut for "use strict ':all'" and people dislike adding a
>> new thing that isn't all.
>>
>> I would like us to get out of this problematic logjam.
>>
>> To that end, I would like to propose that strict.pm and warnings.pm
>> should recognise the same version bundle syntax that feature.pm already
>> does, and builtin.pm will do once anything about it becomes
>> non-experimental. In that way, it would be neat to explain and
>> remember, that e.g.
>>
>> use v5.40;
>>
>> is really a shortcut for
>>
>> use strict ':5.40';
>> use warnings ':5.40';
>> use feature ':5.40';
>> use builtin ':5.40';
>>
>> Currently I am not proposing any actual bundle changes to either of
>> these modules. Both modules would do the same as they do now, when
>> given any bundle number between :5.6 and :5.38 (the new "stable"
>> version as it will be). It's simply to carve out the syntax space for
>> permitting it in future, as currently they fail:
>>
>> $ perl
>> use strict ':5.32';
>> Unknown 'strict' tag(s) ':5.32' at - line 1.
>> BEGIN failed--compilation aborted at - line 1.
>>
>>
>> Once they do support those numbered version bundles, then it would
>> become quite a lot simpler in future to add some new strictness or
>> default-on warning flag, which is dependent on that version number.
>>
>> How do we feel?
>>
>> * Just do it?
>> * Write up a full RFC?
>> * No way because ...?
>>
>
> As I have mentioned in the past, I think this is reasonable for strict,
> but not for warnings. Warnings are meant to be added and modified freely in
> each version without requiring users to opt in to new behavior, and users
> expect to receive new warnings reasonable to the categories/levels they
> have opted into when upgrading Perl without having to change their code.
>

It also begs the question "how to deal with custom warning categories
(warnings::register)

Leon
Re: use strict/warnings version bundles [ In reply to ]
davem at iabyn
Jan 30, 2023, 8:35 AM
Post #11 of 14 (321 views)
Permalink
On Mon, Jan 30, 2023 at 10:55:05AM -0500, Dan Book wrote:
> As I have mentioned in the past, I think this is reasonable for strict, but
> not for warnings. Warnings are meant to be added and modified freely in
> each version without requiring users to opt in to new behavior,

Some of the most angry threads on the p5p mailing list in the past have
been from various users accusing us of something not far short of murder
for adding new warnings which broke their code under "use warnings
'FATAL'" and that we had abandoned all pretence at supporting existing
users and backwards compatibility.

So I for one would welcome a way to add new warnings without risking
further such backlashes.

--
I before E. Except when it isn't.
Re: use strict/warnings version bundles [ In reply to ]
demerphq at gmail
Jan 30, 2023, 8:58 AM
Post #12 of 14 (321 views)
Permalink
On Mon, 30 Jan 2023 at 17:35, Dave Mitchell <davem@iabyn.com> wrote:
>
> On Mon, Jan 30, 2023 at 10:55:05AM -0500, Dan Book wrote:
> > As I have mentioned in the past, I think this is reasonable for strict, but
> > not for warnings. Warnings are meant to be added and modified freely in
> > each version without requiring users to opt in to new behavior,
>
> Some of the most angry threads on the p5p mailing list in the past have
> been from various users accusing us of something not far short of murder
> for adding new warnings which broke their code under "use warnings
> 'FATAL'" and that we had abandoned all pretence at supporting existing
> users and backwards compatibility.
>
> So I for one would welcome a way to add new warnings without risking
> further such backlashes.

+1

I've been doing too much regex hacking. At first I read that last line
as "backslashes" and it still made sense. :-)

/me goes to bed.

cheers,
Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: use strict/warnings version bundles [ In reply to ]
grinnz at gmail
Jan 30, 2023, 9:01 AM
Post #13 of 14 (321 views)
Permalink
On Mon, Jan 30, 2023 at 11:35 AM Dave Mitchell <davem@iabyn.com> wrote:

> On Mon, Jan 30, 2023 at 10:55:05AM -0500, Dan Book wrote:
> > As I have mentioned in the past, I think this is reasonable for strict,
> but
> > not for warnings. Warnings are meant to be added and modified freely in
> > each version without requiring users to opt in to new behavior,
>
> Some of the most angry threads on the p5p mailing list in the past have
> been from various users accusing us of something not far short of murder
> for adding new warnings which broke their code under "use warnings
> 'FATAL'" and that we had abandoned all pretence at supporting existing
> users and backwards compatibility.
>
> So I for one would welcome a way to add new warnings without risking
> further such backlashes.
>

I think there is significant value *to users* in adding new warnings to
existing code without changes. So I think it is a better idea to stick to
our guns (and the documented policy for warnings which at this point such
users are surely aware of). https://perldoc.perl.org/warnings#Fatal-Warnings

The tradeoff is that warnings should only be added to appropriate
categories so people get warnings of the caliber they requested; these
categories are currently "deprecated", "severe" and standard warnings, of
which only the last requires "use warnings". But I have proposed before to
add a new category which is not enabled by a bare "use warnings":
"optional". https://github.com/Perl/perl5/issues/18543

-Dan
Re: use strict/warnings version bundles [ In reply to ]
scott at perturb
Jan 30, 2023, 9:50 AM
Post #14 of 14 (321 views)
Permalink
I'm fine with all of this... just do it.

On 1/30/23 03:13, Paul "LeoNerd" Evans wrote:
> How do we feel?
>
> * Just do it?
> * Write up a full RFC?
> * No way because ...?

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal