-
Notifications
You must be signed in to change notification settings - Fork 542
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
$1 not localized when calling sub #16337
Comments
From @jimavCreated by @jimavThis is a bug report for perl from jim.avera@gmail.com, ----------------------------------------------------------------- I'm guessing this is because the localization of $1 does not also localize If not fixable or catchable, then I'd like to suggest adding an explicit #!/usr/bin/perl sub func($) { func "a123b"; Perl Info
|
From @iabynOn Sat, Dec 23, 2017 at 12:05:35PM -0800, via RT wrote:
$1 et al act like tied variables: whenever their value is retrieved, they This should explain all the behaviour you see.
I can't see any sane way to fix this without introducing weird I suppose in places where $1 et al could get aliased (such as function -- |
The RT System itself - Status changed from 'new' to 'open' |
From @jimavOn 12/28/17 3:40 AM, Dave Mitchell via RT wrote:
It sounds like there's likely nothing to do about it, and making args But I can think of a non-trivial solution... Replace references to $N, %+ and related vars when they appear in -Jim |
From @demerphqOn 28 Dec 2017 12:41, "Dave Mitchell" <davem@iabyn.com> wrote: On Sat, Dec 23, 2017 at 12:05:35PM -0800, via RT wrote:
$1 et al act like tied variables: whenever their value is retrieved, they This should explain all the behaviour you see. We'll, that combined with the fact that perl is a pass by alias language. The op seems to expect pass by value semantics which is simply a
I can't see any sane way to fix this without introducing weird I don't think there is anything to fix. Newcomers to perl encounter this at I suppose in places where $1 et al could get aliased (such as function Are we to do this for every tied object? How are we to know which are A doc patch might be in order but imo no more, vars like $! and $1 are Yves |
From @jimavOn 12/29/17 1:07 AM, yves orton via RT wrote:
Not exactly. Unlike almost anything else in Perl, if $1 is passed as Consider this analogy: sub func($) { local $_ = "bar"; print "func called with $_[0]\n"; } No sane programmer would expect the function to print "bar", and it But this: sub func($) { "bar" =~ /(.*)/; print "func called with $_[0]\n"; } does what no sane programmer would expect, i.e., it prints "bar". Now I think Dave Mitchell's idea of converting $1 to "$1" when passed as |
From @cpansproutOn Fri, 29 Dec 2017 13:35:53 -0800, jim.avera@gmail.com wrote:
Perl already does that with the return value from substr(). This works: $_ = "HELO"; except that the special substr scalar does get its own copy of the substring internally, which is unavoidable due to the requirement that string buffers end in a null.
I wondered for a moment why $1 could not be like a substr scalar, but then I realized: you can modify the original string and $1 does not change. However, $1 currently *does* retrieve its string value dynamically from the pre-match copy, which because of COW is usually the original string buffer. (But, again, because of null-termination, $1 does get its own copy of the string buffer when you use it.)
It wouldn’t be invisible, as referential identity would be lost. It might break a lot of introspection code. -- Father Chrysostomos |
From @demerphqOn 29 December 2017 at 22:35, Jim Avera <jim.avera@gmail.com> wrote:
This is not the same thing. Local changes what SV an identifier local $foo= "bar"; prints out "bar" as I would expect. $_[0] in the case you showed is Put another way, after the local call there are *two* SV's in
It points at the _container_ SV. _data_ implies that it is a value, it It is not uncommon for even experienced Perl programmers to conflate Aliasing occurs at the *container* level.
It does what every experienced Perl programmer would expect. $1 is a container which when used as an rvalue returns the value of func($1) calls func and puts an alias to the container $1 into $_[0]. You could just as easily have said: func("$1") and created a copy. Or you could have written func() like this: sub func { my $thing= shift; "bar" =~ /(.*)/; print "func called and created a copy inside the func instead. This is a standard issue with aliasing. Because @_ contains aliases to Here is an example which I consider to be exactly equivalent to the sub othersub { $_[0]->{x}++ } which prints out: 1:1 Which to me is no different from the regex case. So to me this thread is basically the result of mistaken assumptions I mean, a simple rule is: Operating on @_ directly has subtle implications which may surprise cheers, -- |
From @jimavOn 12/30/17 4:25 AM, yves orton via RT wrote:
Thanks, I understand what you are saying. But a programmer should only The key point is that perlvar says "These variables are read-only and As you mentioned, $1 is not a normal variable but "is a container If $1 were implicitly localized in scopes containing a regex match, but In reality, only the _data_ of match results is dynamically scoped, perl can not localize $1 as long as captured text is not actually stored If this behavior isn't changed, then, perhaps the docs could be modified <perlvar> could say "Capture result data is read-only and <perlre> might say "[as-is: Capture group contents are dynamically |
Migrated from rt.perl.org#132647 (status was 'open')
Searchable as RT132647$
The text was updated successfully, but these errors were encountered: