map{ /.../; { %+ } } @data wrongly flattens hashes into arrays #16519
Comments
From @jimavThis is a bug report for perl from jim.avera@gmail.com, If used inside map{...}, the construct { %+ } results in a flat list of keys and values, not a ref to a hash. map{ /^(?<a>A*)(?<b>B*)$/ or die; { %+ } } ("AB", "AABBB", "AAAB"); returns ('a', 'A', 'b', 'B', 'a', 'AA', 'b', 'BBB', 'a', 'AAA', 'b', 'B') instead of A demo script follows. #!/usr/bin/perl my @list1; print Data::Dumper->Dump([\@list1,\@list2,\@list3], [qw(list1 list2 list3)]); Flags: Site configuration information for perl 5.26.1: Configured by Ubuntu at Fri Feb 23 15:23:43 UTC 2018. Summary of my perl5 (revision 5 version 26 subversion 1) configuration: Locally applied patches: @INC for perl 5.26.1: Environment for perl 5.26.1: |
From @jimav
Okay, this seems to be because the compiler thinks { %+ } is just a nested block, not a hashref constructor. map{ /.../; ( {%+} ) } @data returns a list of hashrefs as expected. Sorry for the noise. |
From @jkeenanOn Fri, 20 Apr 2018 20:25:49 GMT, jim.avera@gmail.com wrote:
Using perlbrew, I checked out various production releases of perl, ran your program in each and recorded the results. See attachment. The program wouldn't compile in 5.8.9, but did in 5.10.1. From 5.10.1 the result was stable up through 5.16.3. As of 5.18.4 the results differ each release. (I haven't looked closely enough to see whether or not this is just reshuffling of hash elements.) So this does not appear to be a regression appearing for the first time in the 5.27 dev cycle. Thank you very much. |
From @jkeenan |
|
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Fri, Apr 20, 2018 at 01:25:49PM -0700, via RT wrote:
An '{' at the start of a statement is ambiguous: it could be the start You can avoid the ambiguity by providing perl with more information; for %a = qw(a 1 b 2); sub f1 { 1; { %a } } # ambiguous print ((f1())[0], "\n"); which outputs: a -- |
From @ilmari"James E Keenan via RT" <perlbug-followup@perl.org> writes:
This is because the regex uses named captures, which were introduced in
This is because %+ is a hash, and hash order is randomised since 5.18.
It is not a bug at all. The reason is that the { %+ } gets interpreted $ perl -MDevel::Dwarn -e 'Dwarn([map{ /^(?<a>A*)(?<b>B*)$/ or die; +{ %+ } } ("AB")])' This ticket should be closed. - ilmari |
From @xsawyerxOn 04/21/2018 10:28 AM, Dave Mitchell wrote:
Also: sub f3 { 1; {; %a } } I picked up the following pattern from rjbs: map +{ 'key' => 'value' }, @values; # hashref expression |
|
@iabyn - Status changed from 'open' to 'rejected' |
From @demerphqOn 21 April 2018 at 10:33, Sawyer X <xsawyerx@gmail.com> wrote:
Really? I call that the abigail pattern. :-)
Yep. Parens also has the same effect iirc. cheers, -- |
From @xsawyerxOn 04/23/2018 10:06 AM, demerphq wrote:
I wouldn't be surprised to learn this is where rjbs got it. :)
|
Migrated from rt.perl.org#133134 (status was 'rejected')
Searchable as RT133134$
The text was updated successfully, but these errors were encountered: