# 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  :-)

Reply via email to