New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some self-referential issue with hash assignment (%h1 = %h1, %h2) #6103
Comments
From @AlexDanielCode: Result: 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. |
From @lizmatFWIW, this feels like a DIHWIDT case
|
The RT System itself - Status changed from 'new' to 'open' |
From @AlexDanielNot really. It is a legitimate assumption that if you can compose a new hash like this, then you can use the same syntax to add to existing hash. In other words, I assumed 「%h1 ,= %h2」 to work like 「%h1.push: %h2」. Or am I missing something? On 2017-02-27 01:36:27, elizabeth wrote:
|
From @geekosaurI disagree; this is not Haskell, if I do something like that then I expect On Mon, Feb 27, 2017 at 4:35 AM, Elizabeth Mattijsen <liz@dijkmat.nl> wrote:
-- |
From @geekosaurAnd yes, I know that it *is* retaining its value as an object pointer, just On Mon, Feb 27, 2017 at 10:46 AM, Brandon Allbery <allbery.b@gmail.com>
-- |
From 1parrota@gmail.comI agree with Brandon on this one. RHS retaining its original value, even when being updated on the LHS On 2/27/17, Brandon Allbery <allbery.b@gmail.com> wrote:
|
From @geekosaurTo unpack this a bit: in this case I understand the comma to be an infix On Mon, Feb 27, 2017 at 11:03 AM, Parrot Raiser <1parrota@gmail.com> wrote:
-- |
From @geekosaurOr to put this another way: the current behavior seems like an On Mon, Feb 27, 2017 at 11:08 AM, Brandon Allbery <allbery.b@gmail.com>
-- |
From @lizmatFWIW, I’m working on a fix
|
From @zoffixznetOn Mon, 27 Feb 2017 07:49:13 -0800, allbery.b@gmail.com wrote:
The claimed clarity isn't so clear to me. If we swap hashes for arrays, then you *don't* <Zoffix> m: my @h1 = 42; my @h2 = 72; @h1 = @h1, @h2; say @h1 I'm surprised you don't get the same with hashes. If you give a comma-separated list of stuff, <Zoffix> m: my %h1 = :42a; my %h2 = :72a; %h1 = 42, 72, %h2; say %h1 You're forced to use an explicit Pair: <Zoffix> m: my %h1 = :42a; my %h2 = :72a; %h1 = %h1 => %h2; say %h1 So to me the bug is this doesn't happen automatically (and that the first key is empty above) |
From @lizmatFixed with rakudo/rakudo@ae7bcf1b8e , more tests needed
|
From @zoffixznetTests added in Raku/roast@3cd5126000 |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#130870 (status was 'resolved')
Searchable as RT130870$
The text was updated successfully, but these errors were encountered: