> On 9 Oct 2017, at 10:38, jn...@jnthn.net via RT > <perl6-bugs-follo...@perl.org> wrote: > > 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.
FWIW, I think this is not a matter of a Array being wrapped into a Scalar. my @A::B and my %A::B *are* scalars, regardless of their sigil. Feels like a case of sigil inspection on the last element of split ‘::’ on the full name, instead of on the first.
