From ipatrol6010@yahoo.com

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​:
rakudo/rakudo@2342871

--ipatrol

From @jnthn

On Sun, 08 Oct 2017 19​:13​:34 -0700, ipatrol6010@​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​:
rakudo/rakudo@2342871

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.

The RT System itself - Status changed from 'new' to 'open'

From @lizmat

On 9 Oct 2017, at 10​:38, jnthn@​jnthn.net via RT <perl6-bugs-followup@​perl.org> wrote​:

On Sun, 08 Oct 2017 19​:13​:34 -0700, ipatrol6010@​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​:
rakudo/rakudo@2342871

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.