|
🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel! Set by lizmat on 6 September 2022. |
|||
|
00:03
yewscion_ joined
00:07
yewscion_ left
|
|||
| 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 | ||
|
00:29
yewscion_ joined
00:34
yewscion_ left
02:34
hulk joined
02:35
kylese left
03:15
hulk left,
kylese joined
04:11
Guest69 left
04:35
yewscion_ joined
04:40
yewscion_ left
05:14
Aedil joined
05:57
guifa left
06:11
Aedil left
06:14
Aedil joined
06:19
yewscion_ joined
06:24
yewscion_ left
07:11
yewscion_ joined
07:15
yewscion_ left
08:36
Aedil left
09:41
abraxxa-home joined
10:33
sena_kun joined
|
|||
| 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 | |
|
11:17
Sgeo left
11:18
yewscion_ joined
11:23
yewscion_ left
12:12
yewscion_ joined
12:16
yewscion_ left
12:46
yewscion_ joined
12:49
guifa joined
12:50
yewscion_ left
12:59
sena_kun left
13:50
Heavy joined
|
|||
| 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! | |||
|
13:52
yewscion_ joined
13:55
Heavy left
13:56
Heavy joined
|
|||
| 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! | |||
|
13:57
yewscion_ left
|
|||
| 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 | |||
|
14:05
Heavy left
14:21
yewscion_ joined
14:25
yewscion_ left
|
|||
| lizmat | that feels like a bug | 14:28 | |
| or, at least an opportunity for optimization | |||
|
14:32
zetaaaa joined,
Aedil joined
|
|||
| 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) |
||
|
14:51
yewscion_ joined
14:56
yewscion_ left
15:06
guifa left
15:11
guifa joined
15:20
yewscion_ joined
15:25
yewscion_ left
17:07
apac joined
17:59
manu_ joined
18:00
eseyman left
18:16
manu_ is now known as eseyman
18:25
sena_kun joined
18:39
guifa left
19:17
guifa joined
20:30
Sgeo joined
21:01
Aedil left
21:28
merp left
21:33
merp joined
22:16
abraxxa-home left
22:57
sena_kun left
23:24
hvxgr left,
hvxgr joined
|
|||