# New Ticket Created by Steve Schulze # Please include the string: [perl #131397] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org/Ticket/Display.html?id=131397 >
Semicolon subscripting in multi dim arrays has odd interactions with indexes that are numeric strings ( but not IntStrings ) See gist: https://gist.github.com/thundergnat/d6dd2d319afc71ee16234c58b3883f0f sub d(*@d) { #say @d; # Debugging my @a = [0, 1], [1, 0]; my $r = 0; for @d -> $c { $r = @a[$r;$c] }; print $r.WHAT.gist, ', '; # Debugging $r }; say d( (1,1,0).List ); say d( (1,1,0).Seq ); say d( (1,1,0).Array ); say d( [1,1,0] ); say d( <1 1 0> ); say d( 1,1,0 ); say d( 110.comb ); # WAT See IRClogs around https://irclog.perlgeek.de/perl6/2017-05-29#i_14654879 <thundergnat> Hmmm. Don't know if this rises to the level of a bug, it it is certainly a WAT at least to me. <thundergnat> m: https://gist.github.com/thundergnat/d6dd2d319afc71ee16234c58b3883f0f <camelia> rakudo-moar 608e88: OUTPUT: «(Int), 0(Int), 0(Int), 0(Int), 0(Int), 0(Int), 0(List), (1)» <lizmat> hmmm.. I guess we could have a .comb candidate for Int that would generate Int's <lizmat> but that feels a bit too magic <thundergnat> lizmat: The weird thing is that the d sub gets an array from .comb like every other instance, it just treats the array subindexing differently. <lizmat> because it gets Str as indexes <thundergnat> as does <1 1 0> but _that_ works as expected... <lizmat> thundergnat: but those are IntStr's <lizmat> so they use the Int candidate <thundergnat> erm... Good point. <lizmat> m: dd <1>, "1" <camelia> rakudo-moar 608e88: OUTPUT: «IntStr.new(1, "1")"1"» <thundergnat> Anyway, As I said not really a bug, but it confused me for about 15 minutes today. <lizmat> thundergnat: I think this WAT warrants a rakudobug fwiw <lizmat> it shouldn't make a difference <thundergnat> Want me to rakudobug it? <thundergnat> lizmat The other odd thing; if I do the subscripting as @d[$r][$c] ( rather than @d[$r;$c] ) it works as expected in all cases. <lizmat> yeah, so the [;] candidate handles Str differently <lizmat> definitely rakudobug this :-)