On Sun, 08 Oct 2017 19:13:34 -0700, ipatrol6...@yahoo.com wrote: > As per a discussion on the IRC channel, I am requesting that a > regression bug be filed regarding the incorrect handling of variables > referenced to packages by the Z and X meta-operators. > > The behavior over time is detailed here: > https://gist.github.com/Whateverable/83ce4a1ea73a429131713367ee23542e > > Of those, the result given from 2015.09 to 2015.11 is the correct and > desired behavior, considering the design documents. > > Doing a bisection: > https://gist.github.com/Whateverable/0a73f0433cee989d7a82ce8a601bd465 > > The regression revision appears to be: > https://github.com/rakudo/rakudo/commit/234287170cb7dd234ffc90271d762b1c106bc57f > I think Z and X are doing the right thing: treating something in a Scalar container as a single item. This is done consistently across the language, so you'll observe this behavior in many more constructs.
The surprise here is that we get a Scalar container in the first place: $ perl6-m -e 'my @A::B = (1..8); say @A::B.VAR.WHAT; my @B = (1..8); say @B.VAR.WHAT' (Scalar) (Array) I suspect that's happening because a package's symbol table is a Stash, which is just a subclass of Hash, and this code is relying on autovivification, which always involves a Scalar container. It probably should instead, somehow, be arranging than an Array is bound directly into the Stash. Then Z, X, and plenty more things would work less surprisingly. A `my %A::B` is likely exhibiting the same kind of problem at the moment too.
