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
RE match variable scope #9855
Comments
From @ig3Created by ian@alula.home.localThis is a bug report for perl from ian@alula.home.local, ----------------------------------------------------------------- perlre says: The numbered match variables ($1, $2, $3, etc.) and the related NOTE: Failed matches in Perl do not reset the match variables, which In a foreach loop I expect that the BLOCK is entered, executed and Thus I expect that numbered match variables created within a loop BLOCK In the following, I expect '1' to be printed only in the first iteration $ perl -wle 'for(1..3){/(1)/; print $1 // "undef"}' I expect the presence of an empty continue block not to make any difference, $ perl -wle 'for(1..3){/(1)/; print $1 // "undef"}continue{}' Consider also: my $_ = '1'; /(.)/; print "before: \$1 = $1\n"; for (2..4) { print "after: \$1 = $1\n"; Which produces before: $1 = 1 The $1 of the outer scope is visible within the loop BLOCK until the Note that the $1 of the outer scope does exist separately and is not merely Again, adding an empty continue BLOCK results in correct behavior: my $_ = '1'; /(.)/; print "before: \$1 = $1\n"; for (2..4) { print "after: \$1 = $1\n"; produces before: $1 = 1 Compare this also with my $var = "outer"; print "before: $var\n"; for (1..3) { print "after: $var\n"; which produces before: outer In this case, as expected, the dynamically scoped $var of the inner scope I think it would be better if the number match variables from a match If there is a reason not to change this behavior then the behavior and Perl Info
|
From @demerphq2009/8/27 ian.goodacre@xtra.co.nz (via RT) <perlbug-followup@perl.org>:
Leaving aside the technicalities involved, would you feel that this is In other words, given that "fixing" this behaviour would probably Im curious as to how people view the trade offs involved here. Yves -- |
The RT System itself - Status changed from 'new' to 'open' |
From @ig3demerphq wrote:
I would probably leave the behavior as it is for two reasons: 1) Existing code might depend on it being as it is and I would break 2) For the same reason that a failed match doesn't reset the numbered Not because I like the way that it is. The rare cases where the Ian |
Migrated from rt.perl.org#68816 (status was 'open')
Searchable as RT68816$
The text was updated successfully, but these errors were encountered: