Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
.splice loses containerization on replacement value #6194
Actually reported as a SO question by brian d foy:
<lizmat> m: my @a = [1,1],[2,2],[3,3]; dd @a; @a.splice: 0, 2, $[4,4]; dd @a # feels like a bug that the containerization of [4,4] is being ignored
I got hit by this with: @a.splice: 0, 0, Any xx 2
On Fri, 08 Sep 2017 18:37:50 -0700, firstname.lastname@example.org wrote:
It's also not specific to `Seq` - it looks like it happens whenever the replacement elements are passed to `splice` as a nested structure rather than as flat arguments:
dd @h; # Array @h = ["a", "b"]
Conceptually¹⁺², the `splice` routine takes the replacements as a `*@` slurpy, so whether they're passed in nested or flat form should not matter.
But Rakudo currently implements the routine with a `| is raw` signature:
say Array.^find_method("splice").signature; # (Mu $: | is raw)
...and apparently does the parameter flattening manually, in a way that introduces this bug.
Until it is fixed, a work-around is to flatten the replacement elements into the argument list of `splice` using `|`:
@a.splice: 0, 0, |(Any xx 2);
On Sun, 16 Apr 2017 12:56:58 -0700, elizabeth wrote:
This ticket and RT#132047 may be merged.
Please find an experimental tree at:
GLR-ize splice's @replacement argument
Collapse **@ and @ candidates into +@ candidates.
(I also tried **@ and it did not fair very well. There are many
splice's prototype never got touched during GLR, if you look at git blame
If someone who is tooled to do an ecosystem-wide/multiplatform test could
Figuring out where this sits WRT 6.d, both feature-wise and technically
No performance tests have been done on this. I notice we still keep some