On Tue Sep 20 13:54:33 2016, jan-olof.hen...@bredband.net wrote:
> # tested with
>
> dogbert@dogbert-VirtualBox ~ $ perl6 -v
> This is Rakudo version 2016.09-19-g8be36b1 built on MoarVM version 2016.09
> implementing Perl 6.c
>
> # the following two examples behave quite differently
>
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my @a = [1,[2,3],4]; dd
> @a.duckmap({ $_ ~~ Int ?? $_ !! Any })' # this works as expected
> (1, (2, 3), 4)
>
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my @a = [1,[2,3],"a"]; dd
> @a.duckmap({ $_ ~~ Int ?? $_ !! Any })' # this will hang or return 'Memory
> allocation failed; could not allocate xxxxxx bytes'
>
> /dogbert17
>
I see why the issue occurs, but have no idea what the correct behaviour should
be.
The docs for .duckmap read "For undefined return values, duckmap will try to
descend into the element if that element implements Iterable." but when would
an undefined Iterable would ever be descendable?
The hang itself happens here:
https://github.com/rakudo/rakudo/blob/e12ebb9/src/core/metaops.pm#L685
The Any returned from your condition is undefined, so duckmap calls the block
with it again, resulting in an infiniloop.
Based on the docs, a check for an Iterable is missing, but it feels wrong to me
that we'd be attempting to "descend" into an undefined Iterable :S
