Mailing List Archive

On 4/9/23 11:01, Ricardo Signes wrote:
> On Friday, I wrote:
>> Part of this is going to be "decide what we do with the question of
>> warnings on smartmatch and the old package separator."  I will post a
>> separate thread about that issue.  My take is "I really hope we can
>> still ship those changes, but we may revert, and the question (to me)
>> is not about /whether/ we see CPAN 'no warnings' tests fail, but
>> /which/ ones."  Expect to see that email sometime today.
>
> Well, I didn't send it Friday or yesterday, but it's still "today" here,
> so here's that email you were waiting for.
>
> *tl;dr*:  I would like to carry out the deprecations as committed,
> although I think the smartmatch one is more questionable.  I would like
> to hear from more of the core team about this.

+1 on the package separator deprecation, but -1 on the smartmatch
deprecation. Not because I want to keep smartmatch (I've never used
it), but ...
>
> The |'|  deprecation went into v5.37.9, before the contentious change
> freeze.  The smartmatch deprecation went into v5.37.10, after.  So,
> starting from the most bureaucratic principles, the smartmatch one is
> more questionable, procedurally, if it is considered contentious.
>

... (assuming your dating of these changes is correct) it's a
contentious change introduced into blead after the point when no
contentious changes may be introduced. I'm always skeptical when we
suspend our own procedures in order to push code out the door. If the
smartmatch deprecation had been introduced earlier in this dev cycle, I
would have had no objection to proceding, notwithstanding the amount of
CPAN breakage.

Thank you very much.
Jim Keenan

On Sun, Apr 09, 2023 at 11:01:41AM -0400, Ricardo Signes wrote:
>
> The `'` deprecation went into v5.37.9, before the contentious change
> freeze. The smartmatch deprecation went into v5.37.10, after. So,
> starting from the most bureaucratic principles, the smartmatch one is
> more questionable, procedurally, if it is considered contentious.
>
> Of the 38 open BBC tickets, 12 are about smartmatch. I think zero are
> about the package separator.

For the record, passing tests are not saying anything about the future.

Here's an example for Acme::Don't on Perl 5.37.11:
http://www.cpantesters.org/cpan/report/863a3562-d60f-11ed-b06c-b6a69dc47836

The test output says:

PERL_DL_NONLAZY=1 "/home/cpan/bin/perl-blead/bin/perl5.37.11"
"-Iblib/lib" "-Iblib/arch" test.pl
1..5
Old package separator "'" deprecated at test.pl line 11.
Old package separator "'" deprecated at blib/lib/Acme/Don/t.pm line 5.
Old package separator "'" deprecated at test.pl line 21.
Old package separator "'" deprecated at test.pl line 24.
Old package separator "'" deprecated at test.pl line 27.
Old package separator "'" deprecated at test.pl line 30.
ok 1
ok 2
ok 3
ok 4
ok 5

When the ' deprecation is enforced, these tests are going to fail for real.

Of course, this is an extreme case (being an Acme module, and
explicitely dependending on the old package separator), but you
get the idea.

At least, distributions that fail on the warnings give us a clear
indication that they need some fixing, instead of failing abruptly
when the deprecation is enforced.

--
Philippe Bruhat (BooK)

When you do not think for yourself, no one thinks for you...
(Moral from Groo The Wanderer #61 (Epic))

James E Keenan wrote:
> On 4/9/23 11:01, Ricardo Signes wrote:
>>
>> [smartmatch: change warning from "experimental" to "deprecated"]
>>
>> ..., if it is considered contentious.
>
> ... it's a contentious change ...

Really?

Admittedly, I've only been following this from the sidelines, but my understanding is that the controversy so far was focused on the question of whether or not to actually remove smartmatch before replacement functionality is available in Core. AFAICS, changing the warning category, which is what this particular change is about, was largely met with strong support.

Also, I'm curious: Does an agreed-upon definition of the term "contentious change" exist? If so, does it take into account whether or not a feature is experimental? I did search for this in perlpolicy and perlglossary, but to no avail.


--
Arne Johannessen
<https://arne.johannessen.de/>

On Sun, Apr 9, 2023 at 9:09?PM Arne Johannessen via perl5-porters <
perl5-porters@perl.org> wrote:

> James E Keenan wrote:
> > On 4/9/23 11:01, Ricardo Signes wrote:
> >>
> >> [smartmatch: change warning from "experimental" to "deprecated"]
> >>
> >> ..., if it is considered contentious.
> >
> > ... it's a contentious change ...
>
> Really?
>
> Admittedly, I've only been following this from the sidelines, but my
> understanding is that the controversy so far was focused on the question of
> whether or not to actually remove smartmatch before replacement
> functionality is available in Core. AFAICS, changing the warning category,
> which is what this particular change is about, was largely met with strong
> support.
>
> Also, I'm curious: Does an agreed-upon definition of the term "contentious
> change" exist? If so, does it take into account whether or not a feature is
> experimental? I did search for this in perlpolicy and perlglossary, but to
> no avail.
>

IMHO, if there's any discussion if something is contentious, it's probably
contentious.

Leon

On Sun, Apr 9, 2023, at 15:09, Arne Johannessen via perl5-porters wrote:
> James E Keenan wrote:
> > ... it's a contentious change ...
>
> Really?
>
> […]
>
> Also, I'm curious: Does an agreed-upon definition of the term "contentious change" exist? If so, does it take into account whether or not a feature is experimental? I did search for this in perlpolicy and perlglossary, but to no avail.

No, but I'd say that if there's ongoing debate among the committers, and there's been no declaration of a ruling from the PSC, it's contentious by common understanding. Now, how contentious was this before it got merged? Probably not very. But if something's effect upon merging becomes contentious, then it is. "We thought this was going to be smooth sailing, but it isn't" feels like a reason to back things out at a late date.

To me, the choppiness we're seeing is largely at the outskirts of things, beyond what worries me, but I am not sole arbiter of the rules of the universe project.

--
rjbs

On Mon, Apr 10, 2023 at 8:03?AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

"We thought this was going to be smooth sailing, but it isn't" feels like
> a reason to back things out at a late date.
>

Without any plan for how to better handle this deprecation, "backing things
out" seems to me to be an abandonment, rather than a deferral.
AIUI, backing out now is an admission that we can't deprecate *anything*
because:
a) warnings can be made fatal
&&
b) some cpan modules are abandoned

Abandonment is an unfortunate reality, but I'm dumbfounded that people
would deliberately write code that treats deprecation warnings as fatal -
thereby sabotaging the "deprecation" procedure.


> To me, the choppiness we're seeing is largely at the outskirts of things,
> beyond what worries me, ...
>

Me, too. I'm leaning towards leaving it in, but largely because I'm
thinking that no better alternative will ever be forthcoming. (A lesser of
two evils.)

Cheers,
Rob

>>>>> On Sun, 09 Apr 2023 11:01:41 -0400, "Ricardo Signes" <
perl.p5p@rjbs.manxome.org> said:

> Of the 38 open BBC tickets, 12 are about smartmatch. I think zero are
about the package separator.

Read https://github.com/Perl/perl5/issues/20782 and count the "also
affected". I count about 8 for the package separator.

--
andreas

On Mon, 10 Apr 2023, 02:27 sisyphus, <sisyphus359@gmail.com> wrote:

>
>
> On Mon, Apr 10, 2023 at 8:03?AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
> wrote:
>
> "We thought this was going to be smooth sailing, but it isn't" feels like
>> a reason to back things out at a late date.
>>
>
> Without any plan for how to better handle this deprecation, "backing
> things out" seems to me to be an abandonment, rather than a deferral.
> AIUI, backing out now is an admission that we can't deprecate *anything*
> because:
> a) warnings can be made fatal
> &&
> b) some cpan modules are abandoned
>
> Abandonment is an unfortunate reality, but I'm dumbfounded that people
> would deliberately write code that treats deprecation warnings as fatal -
> thereby sabotaging the "deprecation" procedure.
>

Fwiw, I don't think that is what is happening. I think the issue is that
people are adding tests that their code does not warn *at all* and are
running those tests as regression tests and not as author tests.

To say "that treats deprecation warnings as fatal" implies that people
thought about deprecation warnings as a specific category, which I find
doubtful, especially as we have no infra to validate if a warning is a
deprecation warning as opposed to some other type of warning.

I don't think it is strange at all that people check their code is warning
free. That they do it as part of normal regression tests is irritating but
also understandable given we really don't document author testing as being
a distinct

>

On Mon, 10 Apr 2023 13:17:02 +0200
demerphq <demerphq@gmail.com> wrote:

> Fwiw, I don't think that is what is happening. I think the issue is
> that people are adding tests that their code does not warn *at all*
> and are running those tests as regression tests and not as author
> tests.
>
> To say "that treats deprecation warnings as fatal" implies that people
> thought about deprecation warnings as a specific category, which I
> find doubtful, especially as we have no infra to validate if a
> warning is a deprecation warning as opposed to some other type of
> warning.
>
> I don't think it is strange at all that people check their code is
> warning free. That they do it as part of normal regression tests is
> irritating but also understandable given we really don't document
> author testing as being a distinct

I was thinking about this on the PSC call, and I've come to the
conclusion that I think that *unguarded* use of e.g. Test::NoWarnings
(or similar) is an antipattern we should be discouraging.

Instead, what I think would be lovely would be to have such a test
marked with an upper bound on its perl version. E.g. if the author
tests that the code should be warning-free on 5.36.0 then the tests
will be silently skipped on any later perl version.

I'll have a hunt around my own modules - I'm sure there are places in
mine where I assert that no warnings come up. It's not specifically
Test::NoWarnings that is the problem, but the overall behaviour. I
recall several of my tests just do a `local $SIG{__WARN__} = ...`
override, so I'll have to look around for some patterns.

Once I have some more concrete suggestions I'll make another post, and
see if we can encourage some change of behaviour on that front.


If they don't do this, then we in core perl have very little freedom to
add new warnings. It would be a shame if "fear of breaking people's
tests" becomes a binding factor that slows down the progress of the
language in this manner.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

Hi there,

On Mon, 10 Apr 2023, Paul "LeoNerd" Evans wrote:

> ... It would be a shame if "fear of breaking people's tests" becomes
> a binding factor that slows down the progress of the language ...

Wouldn't Perl 7 be a better place to break people's tests?

--

73,
Ged.

Op 10-04-2023 om 14:18 schreef Paul "LeoNerd" Evans:
> If they don't do this, then we in core perl have very little freedom to
> add new warnings. It would be a shame if "fear of breaking people's
> tests" becomes a binding factor that slows down the progress of the
> language in this manner.


Although true in general, you can make the case that deprecation
warnings are different in this regard. That is because you have a choice
between breaking peoples code now with a deprecation warning, or later
when the thing is actually deprecated. So I think the discussion is
actually misleading. If you look at it the way people do now, you cannot
win.


So what I think needs to be done is that every module on CPAN gets a
'use X.XXX' declaration so it never warns unless someone explicitly ups
the version requirement. It's a pain, but it's the only way out I think.


HTH,

M4

On Mon, 10 Apr 2023, 13:17 demerphq, <demerphq@gmail.com> wrote:

>
>
> On Mon, 10 Apr 2023, 02:27 sisyphus, <sisyphus359@gmail.com> wrote:
>
>>
>>
>> On Mon, Apr 10, 2023 at 8:03?AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
>> wrote:
>>
>> "We thought this was going to be smooth sailing, but it isn't" feels
>>> like a reason to back things out at a late date.
>>>
>>
>> Without any plan for how to better handle this deprecation, "backing
>> things out" seems to me to be an abandonment, rather than a deferral.
>> AIUI, backing out now is an admission that we can't deprecate *anything*
>> because:
>> a) warnings can be made fatal
>> &&
>> b) some cpan modules are abandoned
>>
>> Abandonment is an unfortunate reality, but I'm dumbfounded that people
>> would deliberately write code that treats deprecation warnings as fatal -
>> thereby sabotaging the "deprecation" procedure.
>>
>
> Fwiw, I don't think that is what is happening. I think the issue is that
> people are adding tests that their code does not warn *at all* and are
> running those tests as regression tests and not as author tests.
>
> To say "that treats deprecation warnings as fatal" implies that people
> thought about deprecation warnings as a specific category, which I find
> doubtful, especially as we have no infra to validate if a warning is a
> deprecation warning as opposed to some other type of warning.
>
> I don't think it is strange at all that people check their code is warning
> free. That they do it as part of normal regression tests is irritating but
> also understandable given we really don't document author testing as being
> a distinct
>

Darn, I sent this prematurely, I meant to put it aside while I took a call.

Anyway, to finish the thought:

[as being a distinct] ... form of testing. We don't advertise the notion of
different types of testing and that you should only do certain types of
tests as author test and not as regression testing.

It is also worth noting such testing is common, there are multiple tools on
CPAN to do it, so clearly there is some level of consensus that it's
reasonable to do /at some level/. For instance on could argue such tests
should be run as "author tests", but the concept isnt well explained and
there is a problem with author testing in that it only tests a devs
personal setup. A module may run warning free on Linux, but throw warnings
on win32, and I find it hard to say that a dev is incorrect in using normal
regression tests to validate that it runs warning free in all targeted
build environments.

So it seems to me that the real problem is not that people test their code
runs warning free, but rather that we haven't encouraged people to disable
deprecation warnings when they do so, and possibly that we have failed to
provide good tools to filter out deprecation warnings.

Cheers
Yves

On Mon, Apr 10, 2023, at 00:05, Andreas Koenig wrote:
> Read https://github.com/Perl/perl5/issues/20782 and count the "also
> affected". I count about 8 for the package separator.

Thanks for that pointer!

--
rjbs

On Mon, 10 Apr 2023, 14:18 Paul "LeoNerd" Evans, <leonerd@leonerd.org.uk>
wrote:

> On Mon, 10 Apr 2023 13:17:02 +0200
> demerphq <demerphq@gmail.com> wrote:
>
> > Fwiw, I don't think that is what is happening. I think the issue is
> > that people are adding tests that their code does not warn *at all*
> > and are running those tests as regression tests and not as author
> > tests.
> >
> > To say "that treats deprecation warnings as fatal" implies that people
> > thought about deprecation warnings as a specific category, which I
> > find doubtful, especially as we have no infra to validate if a
> > warning is a deprecation warning as opposed to some other type of
> > warning.
> >
> > I don't think it is strange at all that people check their code is
> > warning free. That they do it as part of normal regression tests is
> > irritating but also understandable given we really don't document
> > author testing as being a distinct
>
> I was thinking about this on the PSC call, and I've come to the
> conclusion that I think that *unguarded* use of e.g. Test::NoWarnings
> (or similar) is an antipattern we should be discouraging.
>
> Instead, what I think would be lovely would be to have such a test
> marked with an upper bound on its perl version. E.g. if the author
> tests that the code should be warning-free on 5.36.0 then the tests
> will be silently skipped on any later perl version.
>

I suppose that might make sense. You could argue that it should only apply
this rule to deprecation warnings tho.


I'll have a hunt around my own modules - I'm sure there are places in
> mine where I assert that no warnings come up. It's not specifically
> Test::NoWarnings that is the problem, but the overall behaviour. I
> recall several of my tests just do a `local $SIG{__WARN__} = ...`
> override, so I'll have to look around for some patterns.
>
> Once I have some more concrete suggestions I'll make another post, and
> see if we can encourage some change of behaviour on that front.
>
>
> If they don't do this, then we in core perl have very little freedom to
> add new warnings. It would be a shame if "fear of breaking people's
> tests" becomes a binding factor that slows down the progress of the
> language in this manner.
>

Indeed.

Yves

>

On Mon, Apr 10, 2023 at 11:28?AM demerphq <demerphq@gmail.com> wrote:

>
>
> On Mon, 10 Apr 2023, 14:18 Paul "LeoNerd" Evans, <leonerd@leonerd.org.uk>
> wrote:
>
>> On Mon, 10 Apr 2023 13:17:02 +0200
>> demerphq <demerphq@gmail.com> wrote:
>>
>> > Fwiw, I don't think that is what is happening. I think the issue is
>> > that people are adding tests that their code does not warn *at all*
>> > and are running those tests as regression tests and not as author
>> > tests.
>> >
>> > To say "that treats deprecation warnings as fatal" implies that people
>> > thought about deprecation warnings as a specific category, which I
>> > find doubtful, especially as we have no infra to validate if a
>> > warning is a deprecation warning as opposed to some other type of
>> > warning.
>> >
>> > I don't think it is strange at all that people check their code is
>> > warning free. That they do it as part of normal regression tests is
>> > irritating but also understandable given we really don't document
>> > author testing as being a distinct
>>
>> I was thinking about this on the PSC call, and I've come to the
>> conclusion that I think that *unguarded* use of e.g. Test::NoWarnings
>> (or similar) is an antipattern we should be discouraging.
>>
>> Instead, what I think would be lovely would be to have such a test
>> marked with an upper bound on its perl version. E.g. if the author
>> tests that the code should be warning-free on 5.36.0 then the tests
>> will be silently skipped on any later perl version.
>>
>
> I suppose that might make sense. You could argue that it should only apply
> this rule to deprecation warnings tho.
>

I would apply it to all warnings, for the subsequent reasoning presented is
not specific to deprecation warnings. It's always been documented and
expected that Perl will add new warnings to the appropriate categories and
severity when you upgrade Perl. So this version-bounded test seems like
good practice to me. Perhaps Test::NoWarnings could have this feature built
in?

If they don't do this, then we in core perl have very little freedom to
>> add new warnings. It would be a shame if "fear of breaking people's
>> tests" becomes a binding factor that slows down the progress of the
>> language in this manner.
>>
>
-Dan

On Mon, Apr 10, 2023 at 04:37:56PM +0200, demerphq wrote:
>
> So it seems to me that the real problem is not that people test their code
> runs warning free, but rather that we haven't encouraged people to disable
> deprecation warnings when they do so, and possibly that we have failed to
> provide good tools to filter out deprecation warnings.
>

Maybe an easy path (for some of the issue) is to fix Test::NoWarnings to
ignore deprecation warnings (assuming they match a distinctive pattern).

Ignoring deprecation warnings only pushes the problem down the road,
since the modules will definitely break when the deprecation is
effective.

--
Philippe Bruhat (BooK)

Food and life were both meant to be shared with others.
(Moral from Groo The Wanderer #119 (Epic))

On Mon, 10 Apr 2023 11:54:34 -0400
Dan Book <grinnz@gmail.com> wrote:

> I would apply it to all warnings, for the subsequent reasoning
> presented is not specific to deprecation warnings. It's always been
> documented and expected that Perl will add new warnings to the
> appropriate categories and severity when you upgrade Perl. So this
> version-bounded test seems like good practice to me. Perhaps
> Test::NoWarnings could have this feature built in?

Yes; perhaps so. If I come up with what seems to be a reasonable
pattern I'll suggest it there. It'd be good to have it officially
supported/recommended by upstream on that test module.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Mon, 10 Apr 2023 18:04:40 +0200
"Philippe Bruhat (BooK)" <book@cpan.org> wrote:

> Maybe an easy path (for some of the issue) is to fix Test::NoWarnings
> to ignore deprecation warnings (assuming they match a distinctive
> pattern).

$SIG{__WARN__} only has the plain text of the message. It isn't
reliable.

I'm hoping that in the next dev cycle we can start to look more at the
%{^HOOKS} hash that Yves added, and maybe consider adding a
${^HOOKS}{WARN} that has a different calling signature, which would be
passed some sort of context object as well.

${^HOOKS}{WARN} = sub ($ctx, $message, @args) {
return if $ctx->category =~ m/^deprecated::/;
...
};

or somesuch handwaving. I haven't spent more than about 20 seconds
thinking about the detail there, but "something like that".

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

As a newbie here, I might not have a lot useful to add, but I agree that
anybody who's testing their code for never having warnings is obligating
themselves to maintain the code and keep it up to date. The fact is that
the language must develop and evolve, and deprecating things with warnings
is a whole lot better than just dropping things immediately. Also, by
having warnings, even if it causes failed tests, it shows the author "Hey,
there's a problem with how this is written!" that might not even be seen
otherwise. Then they have time to fix it before it just silently dies
entirely when the feature is removed. The simple truth is that if you
wanted to write a static module that isn't maintained, you shouldn't be
testing for a lack of warnings, and the language shouldn't stop evolving
for those who wanted to test for warning-free operation and then never
touch their code again.

Avery


On Tue, 11 Apr 2023 at 00:19, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Mon, 10 Apr 2023 13:17:02 +0200
> demerphq <demerphq@gmail.com> wrote:
>
> > Fwiw, I don't think that is what is happening. I think the issue is
> > that people are adding tests that their code does not warn *at all*
> > and are running those tests as regression tests and not as author
> > tests.
> >
> > To say "that treats deprecation warnings as fatal" implies that people
> > thought about deprecation warnings as a specific category, which I
> > find doubtful, especially as we have no infra to validate if a
> > warning is a deprecation warning as opposed to some other type of
> > warning.
> >
> > I don't think it is strange at all that people check their code is
> > warning free. That they do it as part of normal regression tests is
> > irritating but also understandable given we really don't document
> > author testing as being a distinct
>
> I was thinking about this on the PSC call, and I've come to the
> conclusion that I think that *unguarded* use of e.g. Test::NoWarnings
> (or similar) is an antipattern we should be discouraging.
>
> Instead, what I think would be lovely would be to have such a test
> marked with an upper bound on its perl version. E.g. if the author
> tests that the code should be warning-free on 5.36.0 then the tests
> will be silently skipped on any later perl version.
>
> I'll have a hunt around my own modules - I'm sure there are places in
> mine where I assert that no warnings come up. It's not specifically
> Test::NoWarnings that is the problem, but the overall behaviour. I
> recall several of my tests just do a `local $SIG{__WARN__} = ...`
> override, so I'll have to look around for some patterns.
>
> Once I have some more concrete suggestions I'll make another post, and
> see if we can encourage some change of behaviour on that front.
>
>
> If they don't do this, then we in core perl have very little freedom to
> add new warnings. It would be a shame if "fear of breaking people's
> tests" becomes a binding factor that slows down the progress of the
> language in this manner.
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>

On Mon, Apr 10, 2023 at 4:17?AM demerphq <demerphq@gmail.com> wrote:

> I don't think it is strange at all that people check their code is warning
> free. That they do it as part of normal regression tests is irritating but
> also understandable given we really don't document author testing as being
> a distinct
>

FWIW, I have been doing this in all my cpan tests for many years now:

...
use if $ENV{AUTHOR_TESTING}, 'Test::Warnings';

...which means that warnings will be treated as failures when testing
locally (either by setting the environment variable manually, or when set
via `dzil test`), but not when shipped, which allows warnings from upstream
modules to still exist while not preventing installation.

"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> writes:

> I was thinking about this on the PSC call, and I've come to the
> conclusion that I think that *unguarded* use of e.g. Test::NoWarnings
> (or similar) is an antipattern we should be discouraging.
>
> Instead, what I think would be lovely would be to have such a test
> marked with an upper bound on its perl version. E.g. if the author
> tests that the code should be warning-free on 5.36.0 then the tests
> will be silently skipped on any later perl version.

I think that's hiding the issue too thoroughly. Marking the warning
tests as TODO if they fail (but not if they pass) on a too-new version
of perl would be more appropriate IMO.

- ilmari

On Wed, 12 Apr 2023 16:50:48 +0100
Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> wrote:

> I think that's hiding the issue too thoroughly. Marking the warning
> tests as TODO if they fail (but not if they pass) on a too-new version
> of perl would be more appropriate IMO.

Mmmmm... Yes; that might be a better thing to do, indeed.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Sun, Apr 09, 2023 at 11:01:41AM -0400, Ricardo Signes wrote:
> *tl;dr*: I would like to carry out the deprecations as committed,
> although I think the smartmatch one is more questionable. I would like
> to hear from more of the core team about this.

Skipping most of this thread, which seems to have drifted off into
discussions about things to do in future, and instead coming back to the
specific issue of do we temporarily disable these two deprecation warnings
for 3.38 and then re-enable them early in the 3.39 cycle:

my opinion is yes, disable them for now.

Any new deprecation warning is going to break some modules. We know that
these two new warnings break some modules (or at least break their tests,
or produce noise on STDERR). If we release 5.38.0 in a month's time, many
of these modules will still not yet be fixed. All the outside world will
see is that "p5p have yet again gratuitously broken the perl ecosystem".

I think expecting CPAN authors to rush around and push out new releases of
their modules in a short time frame without good reason is just rude.
Sure, if it was a high priority security issue (like '.' in @INC) you
could justify it; but "'" has been a valid package separator since the
1980's. Test::More's isn't() method has been part of its API for a long
time.

I think giving authors a year to fix their code is a lot more reasonable
than barely 3 months.

Just to be clear, I'm not stating that we should never deprecate things,
I'm just saying that when when do, (especially when gratuitously, as in in
the case of "'"), it should be done early in the yearly release cycle, to
give authors more time, and to provide a longer period of feedback before
it gets irrevocably baked into a production release.

So deferring these two warnings until 5.39.1 is at worst just delaying the
deprecation cycle by a year.

Smartmatch is a bit of a special case. It was *retrospectively* made
experimental, and we can't quite decide what (if anything) should replace
it. I originally proposed deprecating it ASAP, so as to give a "sterile"
period of time during which there would be multiple perl releases where
smartmatch gives deprecation warnings and then fails to compile, to reduce
the chance of a piece of old code silently just changing its behaviour
when run on a new release of perl which just happens to have "fixed"
smartmatch.

But I am now starting to think that we should keep smartmatch, and instead
guard a significant change in behaviour with use feature / use v5.xx.
AIUI, smartmatch isn't buggy as such, it just has some non-intuitive and
overly-complex behaviours. If and when someone comes up with a good
redesign of smartmatch that gains consensus, then people wanting the new
behaviour can just add 'use v5.40' or whatever; existing code gets to keep
the old documented behaviour. Authors of new code can even choose to use
the old behaviour if it does something they think is useful not provided
by the new smartmatch. (Internally this could be implemented by having
two ops, OP_SMARTMATCH and OP_SMARTMATCH2). But if 5.38 deprecates it, then
this breaks the scheme.

So we need to decide whether the old smartmatch behaviour is going away
at some point, or will be kept as a supported feature with any 'new'
smartmatch implementation complementing it rather than replacing it.

If we're agreed that the old smartmatch should be retained, then we should
remove the deprecation.

If we can't yet agree whether the old smartmatch should be retained, then we
should defer the deprecation until such time as we're agreed.

If we agree that the old smartmatch should *not* be retained, then we
we should apply reasoning similar to "'" to decide whether to defer
the deprecation warning to 5.39.1.

--
You never really learn to swear until you learn to drive.

(with my personal hat on)

This seems to be primarily a question about timing. There doesn't seem
to be a huge question about whether to deprecate these things, only a
matter of when we do so.

At the current state of bleadperl, they'll be deprecated when we
release 5.38.0, having therefore given users only 3 or so months of
actual code that has been throwing warnings. But I don't think it's
fair to say that people have "only had 3 months". We've been saying for
years to "please stop using smartmatch", and I feel that nothing in the
core docs has suggested anyone use `'` as a package separator for years
now as well.

I also don't feel that there's much actual difference on the ground
between 3 months and a year. Most of the big "up-river" important dists
that would fix in a year's time, would be just as active and fix in the
past 3 months. Maybe many already have? I suspect if we release 5.38.0
as it stands today, the only dists that have a problem with smartmatch
or tick-as-separator are the "long tail" of little-used,
little-maintained ones that wouldn't have got around to it in another
year by 5.40 anyway.

So where would we stand if we delayed a year? In the same place as we
would be now, but a year later. A lot can be said of Perl's development
process of late but I don't think anyone would currently accuse us of
going "too fast". I think it would be good not to have to wait another
year on this one.

Rik said it best:

> • we *should* deprecate these now, because code that can't be readily
> updated to *at least* add "no warnings '...'" is dead, and we
> shouldn't wait on dead code

He further goes on to question:

> If we strike the deprecation, there is a concrete benefit to a so-far
> theoretical populace. ... Do these people exist? Unclear.

> If we keep the deprecation, there is a nebulous benefit to real
> people. People ... will see that their actual work isn't held back by
> hypothetical audiences whose problems are easy to address.

I'm also swayed by this. If we start to tidy up a few bits and pieces
here and there we have concrete (if small) benefits to real actual
things. With smartmatch out of the way we can do better things (e.g. my
match/case idea). With tick-as-separator gone we can stop confusing
everyone with code like `say "$name's score is $val";`. The downside is
some potential breakage to "some code". OK. Whose code? We've been
asking around on this list for several weeks now for a list of what
*actual* modules are *actually* broken by this and I don't think we've
got such a list. Is there such a list?

Next week, the Perl Toolchain Summit will be taking place in Lyon,
France. Approximately 30 of the top-most upriver distribution authors
will all be together in one place for four days, ready to hack on a
whole bunch of stuff. We now have a 5.37.11 release all ready to test
everything on. I'm fairly sure with a bit of concerted effort we could
go through a large fraction of what users are likely to encounter with
this release, and get it all fixed ready to go.

In summary: I am fully in favour of smartmatch and given/when, and
tick-as-separator both being marked as deprecated in the 5.38.0 release.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/