Deëxperimenting some features - in time for 5.40?

[Paul "LeoNerd" Evans]

Rik points out that we forgot to deëxperiment the "foreach list"
feature, which had been added in 5.36. Fair point.

On the PSC call today we reviewed the contents of perlexperiment.pod to
find a few more things that should be looked into.

A few seem easy:
:const attribute

foreach list

extra paired delimiters [*]

*: But please lets move the full list out of perlfeature.pod and into
some other doc!


One needs a bit of discussion:
try/catch -
I originally wanted to keep this experimental, partly for
considering how to add "typed catch" with filtering (as per
Syntax::Keyword::Try), and partly for thinking about how perl-core
exceptions might turn into real objects.

But it seems that maybe the first of those could just be a new
(experimental) feature on its own, and the second probably ought to
apply to eval+$@ as well, and have its own separate issues to think
about.

So maybe the basic try/catch form as it stands can be
deëxperimented after all...

Also some docs in perlexperiment.pod need fixing:
builtin has changed since the doc was written

feature 'class' needs adding


How do folks feel about declaring these stable (and hence removing the
experimental warnings) as part of 5.39.10, in time for 5.40?
*Technically* this falls outside of the stated change freeze, which is
worded as:

User-visible changes to correctly functioning programs

So, under a strict interpretation, maybe someone could argue that
removing an experimental warning does count as a user-visible change.
But on the other hand, if the program were warning of an experimental
feature, is it correctly-functioning? Does simply removing a warning
that has been suppressed by `no warnings ...` count as a user-visible
change?

Overall in PSC chat we felt that it would be nice to be able to ship a
5.40 where these features are declared stable, no longer printing
experimental warnings. In absence of any objections to the contrary
that's likely what we'll do.

How do people feel about this?

[Darren Duncan]

For any experiment that is considered stable now and would have been
deexperimented already had it been thought of before, I'm definitely on board
that the best move is to deexperiment it immediately for 5.39.10 and not put
that off another year. I feel the benefits of doing it immediately, when we're
sure its stable, outweigh any possible by-the-book violations mentioned. This
means users can be comfortable in using those features a full year sooner, which
is huge. Only hold off deexperimenting something if we're not fully confident
they won't change again soon. -- Darren Duncan

Post by Paul "LeoNerd" Evans
Rik points out that we forgot to deëxperiment the "foreach list"
feature, which had been added in 5.36. Fair point.
On the PSC call today we reviewed the contents of perlexperiment.pod to
find a few more things that should be looked into.
:const attribute
foreach list
extra paired delimiters [*]
*: But please lets move the full list out of perlfeature.pod and into
some other doc!
try/catch -
I originally wanted to keep this experimental, partly for
considering how to add "typed catch" with filtering (as per
Syntax::Keyword::Try), and partly for thinking about how perl-core
exceptions might turn into real objects.
But it seems that maybe the first of those could just be a new
(experimental) feature on its own, and the second probably ought to
about.
So maybe the basic try/catch form as it stands can be
deëxperimented after all...
builtin has changed since the doc was written
feature 'class' needs adding
How do folks feel about declaring these stable (and hence removing the
experimental warnings) as part of 5.39.10, in time for 5.40?
*Technically* this falls outside of the stated change freeze, which is
User-visible changes to correctly functioning programs
So, under a strict interpretation, maybe someone could argue that
removing an experimental warning does count as a user-visible change.
But on the other hand, if the program were warning of an experimental
feature, is it correctly-functioning? Does simply removing a warning
that has been suppressed by `no warnings ...` count as a user-visible
change?
Overall in PSC chat we felt that it would be nice to be able to ship a
5.40 where these features are declared stable, no longer printing
experimental warnings. In absence of any objections to the contrary
that's likely what we'll do.
How do people feel about this?

[Tony Cook]

Post by Paul "LeoNerd" Evans
foreach list

...

Post by Paul "LeoNerd" Evans
How do folks feel about declaring these stable (and hence removing the
experimental warnings) as part of 5.39.10, in time for 5.40?

Do we consider the two reports mentioned in #p5p againt for_list to be
bugs?

The first, https://github.com/Perl/perl5/issues/20297 , I believe
would it require a fundamental change in the implementation to support
declared refs here, but it could be done.

This is about using declared refs with for_list:

for my \%hash (...) { } # works
for my ($key, \%hash) { ... } # syntax error

Perhaps it should be labelled as a feature request.

The other https://github.com/Perl/perl5/issues/20760 is whether
for_list should warn when the remaining elements of the list do not
match the number of scalars declared:

# should this warn on the ($key, $value) = (3) ? (or earlier)
for my ($key, $value) (1, 2, 3) {}

This currently doesn't warn, but I do think whether it should warn is
something that should be decided before for_list loses experimental
status.

Tony

[Dave Mitchell]

Post by Tony Cook
# should this warn on the ($key, $value) = (3) ? (or earlier)
for my ($key, $value) (1, 2, 3) {}
This currently doesn't warn, but I do think whether it should warn is
something that should be decided before for_list loses experimental
status.

Given that the documentation explicitly describes the behaviour in those
circumstances, I think Nicholas intended it to be a feature rather than a
programmer error, so it probably shouldn't warn.

[Paul "LeoNerd" Evans]

On Fri, 29 Mar 2024 11:55:27 +1100

Post by Tony Cook

Post by Paul "LeoNerd" Evans
foreach list

...

Post by Paul "LeoNerd" Evans
How do folks feel about declaring these stable (and hence removing
the experimental warnings) as part of 5.39.10, in time for 5.40?

Do we consider the two reports mentioned in #p5p againt for_list to be
bugs?
The first, https://github.com/Perl/perl5/issues/20297 , I believe
would it require a fundamental change in the implementation to support
declared refs here, but it could be done.
for my \%hash (...) { } # works
for my ($key, \%hash) { ... } # syntax error

However, declared refs and refaliasing are themselves experimental
features:

$ perl -Mv5.38 -e \
'for my \%hash ( {}, {}, {} ) { }'
The experimental declared_refs feature is not enabled at -e line 1.

$ perl -Mv5.38 -Mfeature=declared_refs,refaliasing -e \
'for my \%hash ( {}, {}, {} ) { }'
Declaring references is experimental at -e line 1.
Aliasing via reference is experimental at -e line 1.

Clearly this is at least the overlap of two currently-experimental
things, the non featureflag-enabled foreach-list, and the flag-enabled
refaliasing. It's somewhat a matter of debate as to which one to put
this overlap into, but I'd say it makes things easier to consider this
as "just part of refaliasing generally", as that is still experimental
with some other outstanding questions on it. Declaring such, we can say
that foreach-list with non-refalias variables is then not affected.

Post by Tony Cook
Perhaps it should be labelled as a feature request.

It's either actually a feature request, or part of the refalias
experiment.

Either way, I think it would be best to declare such a thing a new kind
of feature/experiment/request, rather than continue the existing
foreach-list one, so that we can mark this one stable. I'm generally in
favour of more, smaller experiments over fewer, larger ones. It means
we get to declare the stable bits stable sooner, while continuing to
iterate on the edges.

Post by Tony Cook
The other https://github.com/Perl/perl5/issues/20760 is whether
for_list should warn when the remaining elements of the list do not
# should this warn on the ($key, $value) = (3) ? (or earlier)
for my ($key, $value) (1, 2, 3) {}
This currently doesn't warn, but I do think whether it should warn is
something that should be decided before for_list loses experimental
status.

The original PPC document (document number one, at that!) didn't
specifically mention anything about warnings:

https://github.com/Perl/PPCs/blob/main/ppcs/ppc0001-n-at-a-time-for.md

But it does say:

| If the size of the LIST is not an exact multiple of number of iterator
| variables, then on the last iteration the "excess" iterator variables
| are undefined values, much like if you slice beyond the end of an
| array.

This is how I tend to view it.

Other than in terms of sequence and timing, I consider the following to
be very similar:

my ( $x0, $y0, $x1, $y1 ) = qw( red green blue );
say "$x0/$y0";
say "$x1/$y1";

foreach my ( $x, $y ) (qw( red green blue )) {
say "$x/$y";
}

In the first case, the list assignment operator does not warn of
missing values when trying to assign into $y1 (even though the string
interpolation in the `say` call will warn later on). Likewise, I think
the second case should behave the same.

It's already the fact that the new signatured subs create a different
kind of behaviour here - that where missing elements are exceptional
errors. If foreach-list were to warn without error, that would now be a
third different kind of behaviour for what is really the same kind of
situation. I think it's best to keep them all behaving the same, as
much as possible.

((I have some additional thoughts related to this and the possible
creation of a new nicer assignment/binding/destructuring operator
that would behave more like signature unpack, but that's not really
relevant to foreach-list))

[Paul "LeoNerd" Evans]

On Thu, 28 Mar 2024 18:05:51 +0000

Post by Paul "LeoNerd" Evans
How do people feel about this?

Well, everyone sounded pretty positive on the whole idea, so here's a
PR with separate commits per feature.

https://github.com/Perl/perl5/pull/22123