Re: Towards deëxperimenting refalias and/or declared_refs

On Mon, 22 Dec 2025 18:15:44 +0000
"Paul \"LeoNerd\" Evans" <[email protected]> wrote:

> For example:
> 
>   use v5.40;
>   use feature 'refaliasing';
> 
>   my @arr = (1,2,3);
>   sub inner { say "Array is <@arr>" };
>   \@arr = [4,5,6];
>   inner()
> 
>   Aliasing via reference is experimental at ...
>   Array is <1 2 3>
...
> I'd appreciate any comments or thoughts people might have about this
> issue or its possible solution.

I should also note, as I think it needs clarifying: I think all of the
complicated "oops it doesn't work" scenarios around refaliasing are all
of the shape of creating a variable that some other closure can see,
and then later on changing its binding with a refalias operation.

I *think* it's safe to say that these scenarios cannot come up if you
only declare new variables as refaliases, using the declared_refs
feature. So far I've been entirely unable to think up a scenario
related to the above case, using only

  my \@arr = [4,5,6];

So I think it may lead to the idea that we can make the "declared_refs"
feature stable without needing to find any solutions to the more
complex closure problems.


In related news, I found another issue: you can't combine refalias with
multivariable foreach loops:

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

As per my latest comment in there, I think I have an idea for a
solution, which would allow up to 24 variables in a multivar foreach
loop, any subset of which are permitted to be refalias. It's a kindof
weird restriction, but it's better than the currently-zero that is all
that are permitted, and I think should be sufficient for any practical
purpose.

-- 
Paul "LeoNerd" Evans

[email protected]
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS