xinming m: my %h = (:a[1,2], :b[3,4], :c[5,6]); my @t1 = [|%h<a c>]; @t1.raku.say; my @t2 = [%h<a c>]; @t2.raku.say; my @t3 = %h<a c>; @t3.raku.say; 00:18
camelia [[1, 2], [5, 6]]
[[1, 2], [5, 6]]
[[1, 2], [5, 6]]
xinming With this example, @t1 is expected, Now, I'm a got curious, why will the hash slice be "slipped"? also, why will @t3 also work as expected? I mean, for %h<a c> returns a List, But it doesn't slip like the @t2. 00:19
With this example, @t1 is expected, Now, I'm a got curious, why will the hash slice in @t2 be "slipped"? also, also, why @t3 behave like this? I mean, for %h<a c> returns a List, But it doesn't slip like the @t2. 00:20
with @t3, it's an element in an array. But in @t2, It slipped as a list of items into outer array. 00:23
librasteve You are using array literal [] syntax and list assignment to an Array (@-sigil). These both iteratively copy all values and place them in an array. The Hash slice returns a List. So why would you need a slip |? It is just redundant. 10:54
Heavy bisectable: my $a = 10; say $a =:= $a.item; 13:51
bisectable6 Heavy, Will bisect the whole range automagically because no endpoints were provided, hang tight
Heavy, ¦6c (86 commits): «True␤»
Heavy, Nothing to bisect!
Heavy bisectable: my $a = 10; say $a =:= item($a); 13:56
bisectable6 Heavy, Will bisect the whole range automagically because no endpoints were provided, hang tight
Heavy, ¦6c (86 commits): «False␤» 13:57
Heavy, Nothing to bisect!
Heavy hm, makes you scratch your head a little bit 13:58
aren't item(...) and .item meant to work the same way? 14:00
actually, $(...) and item(...) don't work the same either
lizmat that feels like a bug 14:28
or, at least an opportunity for optimization
timo so item($a) should not give you a fresh container? 14:34
m: my $a = 10; my \one := $a; my \two := item($a); dd :$a, one => one, two => two; one = 99; dd :$a, one => one, two => two 14:35
camelia :a(10)
:one(10)
:two(10)
:a(99)
:one(99)
:two(10)