Towards deëxperimenting refalias and/or declared_refs
[email protected] ("Paul \"LeoNerd\" Evans")
| Newsgroups | perl.perl5.porters |
|---|---|
| Message-ID | <[email protected]> |
We have two closely-related features, `refaliasing` and
`declared_refs`, that are currently both marked as experimental.
They've been in this state for a while now, so I'm trying to get to the
bottom of why, and whether we can mark them as stable. These also
relate to the new PPC0034 document, which proposes adding refalias
arguments to signatures.
The two GH issues relating to these are:
https://github.com/Perl/perl5/issues/14150 (refaliasing)
https://github.com/Perl/perl5/issues/15458 (declared_refs)
From an initial investigation, it appears the only real sticking point
left here is the behaviour of the refalias action when applied to
variables that are captured by closures. In particular, because of the
current way that refalias is implemented, it means that performing a
refalias operation on a variable that is supposed to be shared between
multiple scopes (i.e. closures) will break the aliasing between those
scopes.
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>
Here it is likely the intended behaviour was to print <4 5 6>.
I have been thinking a lot about this, and I can't think of a better
way to implement it so that this doesn't break. Either:
* any variable that is the target of a refalias operation has to store
a (runtime dynamic) list of *all* the locations in all the pads it
is aliased into, so that they can all be updated, or
* any refaliased variable has to somehow be implemented at an extra
pointer level of distance away.
Both of these ideas have downsides in terms of CPU and memory costs.
Lacking any better ideas there then, I have instead looked into whether
it would be possible to add better warnings around these cornercases of
closure capture, which would hopefully allow us to remove the overall
experimental status of what is otherwise a useful feature. I have a
(currently-draft) PR open for adding such a warning, though it isn't
quite ideal for reasons I explain in this comment:
https://github.com/Perl/perl5/pull/24026#issuecomment-3683205837
I'd appreciate any comments or thoughts people might have about this
issue or its possible solution.
--
Paul "LeoNerd" Evans
[email protected]
http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS