On Sat, 09 Dec 2017 13:19:23 -0800, elizabeth wrote: > If that shouldn’t work, or work differently, it can be ripped > out / replaced. If that should work, then we need to look at fixing > -put-.
IMO it should work, considering you can't nqp::unbox_n/nqp::unbox_i Junctions either, yet we don't have Junction-related explosions with numeric stuff. I also found another issue: IO::Handle.print/put infiniloop in dispatch when given a Junction. > FWIW, I would also expect it to junct. I started a fix down that path, but it kinda looks gross and dirty. Similar thing would be needed in src/core/io_operators.pm for subroutine versions. The Junctions go through the **@foo slurpy candidates and the explosions then happen inside optimizations, where we assume x.Str gives an unboxable Str. Is there a better way? Here's my thing: 2017.11.50 zoffix@VirtualBox~/CPANPRC/rakudo (master)$ gd diff --git a/src/core/IO/Handle.pm b/src/core/IO/Handle.pm index 55ff911..0303047 100644 --- a/src/core/IO/Handle.pm +++ b/src/core/IO/Handle.pm @@ -652,6 +652,11 @@ my class IO::Handle { multi method print(IO::Handle:D: **@list is raw --> True) { # is raw gives List, which is cheaper self.print(@list.join); } + multi method print(IO::Handle:D: Junction \j --> True) { + # junct the Junction. Without this candidate, we'd go through the + # **@list slurpy candidate and dispatch infiniloop. + -> Any \el { self.print: el }(j) + } proto method put(|) {*} multi method put(IO::Handle:D: Str:D \x --> True) { @@ -662,6 +667,11 @@ my class IO::Handle { multi method put(IO::Handle:D: **@list is raw --> True) { # is raw gives List, which is cheaper self.put(@list.join); } + multi method put(IO::Handle:D: Junction \j --> True) { + # junct the Junction. Without this candidate, we'd go through the + # **@list slurpy candidate and dispatch infiniloop. + -> Any \el { self.put: el }(j) + } multi method say(IO::Handle:D: Str:D $x --> True) { $!decoder or die X::IO::BinaryMode.new(:trying<say>);