On Sun, 16 Apr 2017 12:56:58 -0700, elizabeth wrote: > Actually reported as a SO question by brian d foy: > > http://stackoverflow.com/questions/43437664/how-can-i-get-around-a- > slurpy-parameter-in-the-perl-6-signature > > > <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 > <+camelia> rakudo-moar 188711: OUTPUT: «Array @a = [[1, 1], [2, > 2], [3, 3]]Array @a = [4, 4, [3, 3]]» > <jnthn> lizmat: Yeah, it's because there's a candidate with @new at > the end that it binds to, decontainerizing it in the process. > <jnthn> So it's not actually hitting the slurpy at all > <lizmat> so you agree it's wrong atm > <jnthn> The slurpy is **@foo > <jnthn> So in fact if it *was* hitting the slurpy it would be behaving > right :) > <jnthn> Yeah, it's wrong to discard the itemization > <lizmat> ok, so we are in agreement > <jnthn> I wonder if it was untested and then accidentally regressed > when splice was optimized by breaking it out into a bunch of > candidates > <lizmat> will file a rakudobug > <jnthn> Since I seem to recall splice getting at least something of a > look during the GLR > <jnthn> And I can't imagine we settled on "it ignores itemization" :) > <jnthn> bisectable6: my @a = [1,1],[2,2],[3,3]; @a.splice: 0, 2, > $[4,4]; dd @a > <+bisectable6> jnthn, On both starting points (old=2015.12 > new=1887114) the exit code is 0 and the output is identical as well > <+bisectable6> jnthn, Output on both points: «Array @a = [4, 4, [3, > 3]]» > <jnthn> Hm, nope > <jnthn> It's been like that since Christmas > <lizmat> ok, doesn't make it right, though :-) > <jnthn> Indeed > <lizmat> but will wait for the release to look at fixing it > <jnthn> *nod*
This ticket and RT#132047 may be merged. Please find an experimental tree at: https://github.com/skids/rakudo/tree/rt131162 commit 998738620d1ca327e1b2d7727b7a0f28b9bce542 Author: skids <b...@abrij.org> Date: Fri Sep 15 21:01:48 2017 -0400 GLR-ize splice's @replacement argument Collapse **@ and @ candidates into +@ candidates. This is a spec/doc change. Will need to be reconciled. May need to figure out how to make this 6.d-only (or later) Amazingly, passes all spectests. Fixes RT#131162 and RT#132047 Needs ecosystem-wide testing for fallout (I also tried **@ and it did not fair very well. There are many specttests that assume single-argument-rule behavior on single arguments.) splice's prototype never got touched during GLR, if you look at git blame in specs. It just got missed, I guess. Probably not the only one. If someone who is tooled to do an ecosystem-wide/multiplatform test could try this tree we could get an idea how disruptive it would be. Figuring out where this sits WRT 6.d, both feature-wise and technically as to how we best replace 6.c's Array candidates or dispatcher. No performance tests have been done on this. I notice we still keep some core code doing +@ by hand but don't know if that is due to performance or just because they were implemented before we had that slurpy modifier, or due to a needed behavioral quirk.
