Mailing List Archive

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

On 2024-03-28 11:05 a.m., Paul "LeoNerd" Evans wrote:
> 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?
>

On Thu, Mar 28, 2024 at 11:06?AM Paul "LeoNerd" Evans <
leonerd@leonerd.org.uk> wrote:

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

> User-visible changes to correctly functioning programs
>

Correctly-functioning programs would have already suppressed the warning,
so removing the warning is a no-op to these programs. So I think you're
still fine to remove the warnings for 5.39.10.

How do people feel about this?
>

I have warm and fuzzy feelings about this. Let's do it!

On Thu, Mar 28, 2024 at 06:05:51PM +0000, Paul "LeoNerd" Evans wrote:
> foreach list
...
> 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

On Fri, Mar 29, 2024 at 11:55:27AM +1100, Tony Cook wrote:
> # 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.

--
The crew of the Enterprise encounter an alien life form which is
surprisingly neither humanoid nor made from pure energy.
-- Things That Never Happen in "Star Trek" #22

On Fri, 29 Mar 2024 11:55:27 +1100
Tony Cook <tony@develop-help.com> wrote:

> On Thu, Mar 28, 2024 at 06:05:51PM +0000, Paul "LeoNerd" Evans wrote:
> > foreach list
> ...
> > 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

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.

> 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.


> 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.

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

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

>
> 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.


+1

Please consider de-experimenting all four (:const, foreach, extra paired
delimiters, try/catch) additions mentioned, so we can use them as stable
language features without warnings and boilerplates to disable thereof.



On Thu, Mar 28, 2024 at 7:06?PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> 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?
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>

On Thu, 28 Mar 2024 18:05:51 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> 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

--
Paul "LeoNerd" Evans

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