Interpolation of @{^CAPTURE} and its friends doesn't work #16050
Comments
From ishigaki@cpan.orgCreated by ishigaki@cpan.orgInterpolation of newly introduced @{^CAPTURE} and its friends doesn't work well. $ perl -E '"a"=~/(.)/; say $ perl -E '"a"=~/(.)/; say @{^CAPTURE}; say "@{^CAPTURE}"' $ perl -E '"a"=~/(?<b>.)/; say $ perl -E '"a"=~/(?<b>.)/; say %{^CAPTURE}; say "%{^CAPTURE}"' $ perl -E '"a"=~/(?<b>.)/; say @{^CAPTURE}{b}; say "@{^CAPTURE}{b}"' $ perl -E '"a"=~/(?<b>.)/; say %{^CAPTURE}{b}; say "%{^CAPTURE}{b}"' $ perl -E '"a"=~/(?<b>.)/; say $ perl -E '"a"=~/(?<b>.)/; say %{^CAPTURE_ALL}; say "%{^CAPTURE_ALL}"' $ perl -E '"a"=~/(?<b>.)/; say @{^CAPTURE_ALL}{b}; say "@{^CAPTURE_ALL}{b}"' $ perl -E '"a"=~/(?<b>.)/; say %{^CAPTURE_ALL}{b}; say "%{^CAPTURE_ALL}{b}"' Hope this helps. Perl Info |
From @AbigailOn Tue, Jun 27, 2017 at 12:48:37AM -0700, Kenichi Ishigaki wrote:
That has nothing to do with @{^CAPTURE}, but how interpolation works: $ perl -E '@foo = qw [a b c]; say "${foo}[0]"' Interpolation works this way on purpose, the braces around the name There's an ugly workaround: $ perl -E '"foo" =~ /(foo)/; say "${\${^CAPTURE}[0]}"'
Hashes don't interpolate in perl5. Abigail |
|
The RT System itself - Status changed from 'new' to 'open' |
From ishigaki@cpan.orgOn Tue, 27 Jun 2017 23:37:14 -0700, abigail@abigail.be wrote:
Thanks for clarification. I was surprised when I first tested them, but surely the current behavior is natural if they aren't special-cased. Kenichi
|
From @demerphqOn 28 June 2017 at 08:37, Abigail <abigail@abigail.be> wrote:
I thought it was so that you could do "${foo}o" safely. I am actually really surprised to hear this, since using the braces After all these years I never once noticed this behavior. Sigh. cheers, -- |
From @AbigailOn Wed, Jun 28, 2017 at 12:05:42PM +0200, demerphq wrote:
That as well of course.
Multicharacter caret vars are relatively new (5.8, or 5.10, IIRC). And Abigail |
From Eirik-Berg.Hanssen@allverden.noOn Wed, Jun 28, 2017 at 12:05 PM, demerphq <demerphq@gmail.com> wrote:
I thought I'd found a workaround (or rather, working interpolation (Huh?) Odd, since "${foo[0]}" obviously works (although I'm not sure it's eirik@purplehat[18:00:40] This is perl 5, version 26, subversion 0 (v5.26.0) built for x86_64-linux Copyright 1987-2017, Larry Wall Perl may be copied only under the terms of either the Artistic License or Complete documentation for Perl, including FAQ lists, should be found on eirik@purplehat[18:00:57]~$ So, um, yeah, I thought "${^CAPTURE[0]}" would interpolate the same way … is that a bug? Eirik |
From @AbigailOn Wed, Jun 28, 2017 at 06:04:08PM +0200, Eirik Berg Hanssen wrote:
I never knew that "${foo[0]}" worked. If it's not documented, I'm
No idea :\ Abigail |
From @xsawyerxOn 06/28/2017 06:27 PM, Abigail wrote:
I would say I find interpolation here a desired behavior, instead of not |
From @demerphqOn 29 June 2017 at 06:54, Sawyer X <xsawyerx@gmail.com> wrote:
Reading the code I think this is a bug. The code that handles caret vars was added to code handling ${ in Inline Patchdiff --git a/toke.c b/toke.c
index 0dcf623..2869431 100644
--- a/toke.c
+++ b/toke.c
@@ -9363,6 +9363,7 @@ S_scan_ident(pTHX_ char *s, char *dest, STRLEN
if ( !tmp_copline ) Makes them work equivalently. That the goto form is possible argues in Inline Patchdiff --git a/toke.c b/toke.c
index 0dcf623..5f19e1d 100644
--- a/toke.c
+++ b/toke.c
@@ -9352,19 +9352,32 @@ S_scan_ident(pTHX_ char *s, char *dest, STRLEN
if ( !tmp_copline ) But I have to wonder if the part that says: + tmp_copline = CopLINE(PL_curcop); should also be shared. Yves |
From @demerphqOn 29 June 2017 at 09:51, demerphq <demerphq@gmail.com> wrote:
Turns out this was the wrong way around, we have to rule out utf8 I pushed a fix, with no tests as yet, to smoke-me/rt_131664 Ill push the tests later if noone beats me to it. FWIW, i have been testing with: ./perl -le'"foo"=~/(.+)/; print "${^CAPTURE [0] }"' which should print "foo" obviously, and not die. cheers, |
From @demerphqOn 29 June 2017 at 11:35, demerphq <demerphq@gmail.com> wrote:
And I have deleted and recreated that branch with on it now, which includes tests. Yves |
From @xsawyerxOn 06/29/2017 12:51 AM, demerphq wrote:
Reading back, this was vague. I consider it undesirable that it does not Thank you for a quick resolution to this. |
From zefram@fysh.orgThe behaviour here is not a bug. The rule that braces fully delimit If this rule were to be changed, it would require a deprecation cycle. -zefram |
From @cpansproutOn Sat, 30 Dec 2017 04:04:26 -0800, zefram@fysh.org wrote:
Was Yves’s patch for ${^CAPTURE[0]} ever applied? -- Father Chrysostomos |
From @demerphqOn 30 December 2017 at 16:18, Father Chrysostomos via RT
This ticket included discussion of two aspects of this problem. One is
Yes, in 4f08ed8, aka 5.27.2. But again, just to be clear, that was a slightly different issue from cheers, -- |
From @demerphqOn 30 December 2017 at 13:04, Zefram <zefram@fysh.org> wrote:
I think you have not read the ticket in detail, and are paying too The subject of this ticket is "Interpolation of @{^CAPTURE} and it's This was actually true, as the notation "${^CAPTURE[0]}" did not work $ git log --grep 'Parse caret vars with subscripts' Parse caret vars with subscripts the same as normal vars inside of This behavior is discussed in perl #131664, which complains that So this patch makes "${^CAPTURE[0]}" (and "${^CAPTURE [0]}" [hi You are correct the body recommended a syntax that is not right, but So as far as I am concerned this ticket can be closed as *fixed*. If you wish, you can close this ticket as wont fix, and then create a Regardless I agree this matter is closed. cheers, -- |
From zefram@fysh.orgdemerphq wrote:
Sorry, I did miss the index-inside-braces aspect somehow. I'm happy -zefram |
|
@cpansprout - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release yesterday of Perl 5.28.0, this and 185 other issues have been Perl 5.28.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
p5pRT commentedJun 27, 2017
Migrated from rt.perl.org#131664 (status was 'resolved')
Searchable as RT131664$
The text was updated successfully, but these errors were encountered: