I agree with Brandon on this one. RHS retaining its original value, even when being updated on the LHS is a fundamental behaviour in Perl. Changing that, especially in obscure special circumstances would be bad.
On 2/27/17, Brandon Allbery <allber...@gmail.com> wrote: > And yes, I know that it *is* retaining its value as an object pointer, just > not the contents. But if I write something like that, I pretty clearly mean > the *contents*. > > On Mon, Feb 27, 2017 at 10:46 AM, Brandon Allbery <allber...@gmail.com> > wrote: > >> I disagree; this is not Haskell, if I do something like that then I >> expect >> %h2 to retain its original value while the RHS is being evaluated. >> >> On Mon, Feb 27, 2017 at 4:35 AM, Elizabeth Mattijsen <l...@dijkmat.nl> >> wrote: >> >>> FWIW, this feels like a DIHWIDT case >>> >>> > On 27 Feb 2017, at 00:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) < >>> perl6-bugs-follo...@perl.org> wrote: >>> > >>> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev >>> > # Please include the string: [perl #130870] >>> > # in the subject line of all future correspondence about this issue. >>> > # <URL: https://rt.perl.org/Ticket/Display.html?id=130870 > >>> > >>> > >>> > Code: >>> > my %h1 = <1 a 2 b>; >>> > my %h2 = <3 c 4 d>; >>> > my %h3 = <5 e 6 f>; >>> > %h2 = %h1, %h2, %h3; >>> > say %h2 >>> > >>> > Result: >>> > {1 => a, 2 => b, 5 => e, 6 => f} >>> > >>> > >>> > Notice that it has everything except for elements of %h2. >>> > >>> > If this behavior is correct, then it should throw a warning. But I'd >>> argue that it should work exactly the same way as if it was an >>> assignment >>> to a different hash. >>> >> >> >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allber...@gmail.com >> ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
