From zefram@fysh.org

$ ./perl6 -e 'my @​a of Int; say @​a.of, " ", @​a.WHAT; my @​b; say @​b.of, " ", @​b.WHAT'
(Int) (Array[Int])
(Mu) (Array[Int])

The first array here is accurately described as Array[Int], matching
the declaration. The second has no element type constraint declared, so
could be accurately described as Array[Mu] or just as Array, but it claims
to be an Array[Int]. It actually behaves as declared, as Array[Mu].

Things get even weirder if the second array has an "of" type too​:

$ ./perl6 -e 'my @​a of Int; say @​a.of, " ", @​a.WHAT; my @​b of Str; say @​b.of, " ", @​b.WHAT'
(Int) (Array[Int][Str])
(Str) (Array[Int][Str])

Now both array declarations have contributed parts to a single array
class seen by both array objects. The expression by which this class
is described causes an error if evaluated.

This bizarre behaviour does not occur if the type constraints are
expressed in prefix form. If one of the arrays uses prefix syntax and
the other "of", or one no explicit element type and the other "of", then
various results are seen, mostly involving some of this bizarre behaviour.

-zefram

From @zoffixznet

Thanks for the report.

This has been fixed sometime pre-Christmas.
Tests added in Raku/roast@feb0022c7d

On Mon Sep 21 15​:25​:42 2015, zefram@​fysh.org wrote​:

$ ./perl6 -e 'my @​a of Int; say @​a.of, " ", @​a.WHAT; my @​b; say @​b.of,
" ", @​b.WHAT'
(Int) (Array[Int])
(Mu) (Array[Int])

The first array here is accurately described as Array[Int], matching
the declaration. The second has no element type constraint declared,
so
could be accurately described as Array[Mu] or just as Array, but it
claims
to be an Array[Int]. It actually behaves as declared, as Array[Mu].

Things get even weirder if the second array has an "of" type too​:

$ ./perl6 -e 'my @​a of Int; say @​a.of, " ", @​a.WHAT; my @​b of Str; say
@​b.of, " ", @​b.WHAT'
(Int) (Array[Int][Str])
(Str) (Array[Int][Str])

Now both array declarations have contributed parts to a single array
class seen by both array objects. The expression by which this class
is described causes an error if evaluated.

This bizarre behaviour does not occur if the type constraints are
expressed in prefix form. If one of the arrays uses prefix syntax and
the other "of", or one no explicit element type and the other "of",
then
various results are seen, mostly involving some of this bizarre
behaviour.

-zefram

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

@zoffixznet - Status changed from 'open' to 'resolved'