Repository navigation
List::Util attaching to the wrong $_ when used inside given/when construct #9798
Description
Activity
From vparseval@gmail.com
Created by vparseval@gmail.com
Please behold the following:
#!/usr/bin/perl -l
use feature qw/switch/;
use List::Util qw/first/;my $val = 1;
given ($val) {# my $_
when (1) {
print +(first { $_ == 10 } 10 .. 15) ? 'works inside when'
: 'broken inside when';
}
}
print +(first { $_ == 10 } 10 .. 15) ? 'works outside when'
: 'broken outside when';
__END__
broken inside when
works outside whenNote that when commenting out the lexical declaration of $_, the code behaves
as expected.At this point, I am not sure if the problem is in List::Util or the perl core.
List::MoreUtil uses does the same thing as List::Util when it comes to
assigning to $_ and dispatching the code-reference hence it's suffering from
the same malaise.Cheers,
TassiloPerl Info
Flags: category=library severity=low Site configuration information for perl 5.10.0: Configured by Debian Project at Sun May 3 21:49:06 UTC 2009. Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.6.18-xen-3.1-1-amd64, archname=x86_64-linux-gnu-thread-multi uname='linux nautilus 2.6.18-xen-3.1-1-amd64 #1 smp fri oct 19 23:35:59 cest 2007 x86_64 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.3.3', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.9.so, so=so, useshrplib=true, libperl=libperl.so.5.10.0 gnulibc_version='2.9' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib' Locally applied patches: @INC for perl 5.10.0: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . Environment for perl 5.10.0: HOME=/home/ethan LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/ethan/bin:/home/ethan/bin:/usr/local/bin:/usr/bin:/bin:/usr/games PERL_BADLANG (unset) SHELL=/bin/bashFrom p5p@perl.wizbit.be
-----------------------------------------------------------------
[Please enter your report here]Please behold the following:
[code snipped]
Note that when commenting out the lexical declaration of $_, the code behaves
as expected.No it doesn't. Or at least not for me. I suggest you check your test
case again.This seem to happen because given creates a lexical $_. It also
happens when for/foreach is used with a lexical $_:#!/usr/bin/perl -l
use strict;
use warnings;
use feature qw/switch/;sub s1 (&) {
my $code = shift;
for ("a") {
print "\ts1:\t \$_ = " . \$_ . " (value: $_)";
$code->();
}
}print "Given/when block:";
my $val = 1;
given ($val) {
when (1) {
print "\twhen-1:\t \$_ = " . \$_ . " (value: $_)";
s1 { print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; };
print "\twhen-2:\t \$_ = " . \$_ . " (value: $_)";
}
}print "";
print "For loop";
for (1) {
print "\tfor-1:\t \$_ = " . \$_ . " (value: $_)";
s1 { print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; };
print "\tfor-2:\t \$_ = " . \$_ . " (value: $_)";
}print "";
print "For loop with lexical \$_";
for my $_ (1) {
print "\tfor-1:\t \$_ = " . \$_ . " (value: $_)";
s1 { print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; };
print "\tfor-2:\t \$_ = " . \$_ . " (value: $_)";
}
__END__$ perl-5.10.0 rt-67694.pl
Given/when block:
when-1: $_ = SCALAR(0x994f768) (value: 1)
s1: $_ = SCALAR(0x994f478) (value: a)
block: $_ = SCALAR(0x994f768) (value: 1)
when-2: $_ = SCALAR(0x994f768) (value: 1)For loop
for-1: $_ = SCALAR(0x994ed08) (value: 1)
s1: $_ = SCALAR(0x994f478) (value: a)
block: $_ = SCALAR(0x994f478) (value: a)
for-2: $_ = SCALAR(0x994ed08) (value: 1)For loop with lexical $_
for-1: $_ = SCALAR(0x994e848) (value: 1)
s1: $_ = SCALAR(0x994f478) (value: a)
block: $_ = SCALAR(0x994e848) (value: 1)
for-2: $_ = SCALAR(0x994e848) (value: 1)Best regards,
Bram
The RT System itself - Status changed from 'new' to 'open'
From @rgs
2009/7/21 Bram <p5p@perl.wizbit.be>:
This seem to happen because given creates a lexical $_. It also happens when
for/foreach is used with a lexical $_:Hmm what ? No, given does not create a lexical $_ : from pp_entergiven :
if (PL_op->op_targ == 0) {
SV ** const defsv_p = &GvSV(PL_defgv);
*defsv_p = newSVsv(POPs);
SAVECLEARSV(*defsv_p);
}
else
sv_setsv(PAD_SV(PL_op->op_targ), POPs);(rewriting that with the proper macros will be nice) (not sure if
there is absolutely no bug there)What happens, at first glance, it that List::Util always uses the
global $_. (an "our $_" in the "first" block should solve the pb).We provide UNDERBAR and dUNDERBAR macros to access the current $_, be
it lexical or global.However we don't have (yet) an API to localize the current $_ as
needed in grep-like functions.I suppose that code from pp_grepstart could be copied in List::Util to
solve the bug.From p5p@perl.wizbit.be
Citeren Rafael Garcia-Suarez <rgarciasuarez@gmail.com>:
2009/7/21 Bram <p5p@perl.wizbit.be>:
This seem to happen because given creates a lexical $_. It also happens when
for/foreach is used with a lexical $_:Hmm what ? No, given does not create a lexical $_ :
I didn't look at the code only at the docs and the output :/
from perldoc perlsyn:
'given(EXPR) will assign the value of EXPR to $_ within the lexical
scope of the block, so it's similar to do { my $_ = EXPR; ... }'the output shows a different reference for $_ in the when block and in
the s1 subfrom pp_entergiven :
if \(PL\_op\->op\_targ == 0\) \{ SV \*\* const defsv\_p = &GvSV\(PL\_defgv\); \*defsv\_p = newSVsv\(POPs\); SAVECLEARSV\(\*defsv\_p\); \} else sv\_setsv\(PAD\_SV\(PL\_op\->op\_targ\)\, POPs\);What happens, at first glance, it that List::Util always uses the
global $_. (an "our $_" in the "first" block should solve the pb).Then what does in create in pp_entergiven?
Doesn't it modify PL_defgv?
(I have to admit being not familiar enough with the code to really
read/understand it :( )Adding an our $_ does solve the problem:
With 's1 { our $_; print "\tblock:\t \$_ = " . \$_ . " (value: $_)";
};' the output becomes:Given/when block:
when-1: $_ = SCALAR(0x942d7f0) (value: 1)
s1: $_ = SCALAR(0x942d500) (value: a)
block: $_ = SCALAR(0x942d500) (value: a)
when-2: $_ = SCALAR(0x942d7f0) (value: 1)But why is this be nessesary?
If given() does not create a lexical $_ then shouldn't the $_ in the
block be the same as the global $_?We provide UNDERBAR and dUNDERBAR macros to access the current $_, be
it lexical or global.However we don't have (yet) an API to localize the current $_ as
needed in grep-like functions.I suppose that code from pp_grepstart could be copied in List::Util to
solve the bug.That would only work for the XS version right?
(There is also a Pure Perl version...)Best regards,
Bram
From @rgs
2009/7/21 Bram <p5p@perl.wizbit.be>:
Citeren Rafael Garcia-Suarez <rgarciasuarez@gmail.com>:
2009/7/21 Bram <p5p@perl.wizbit.be>:
This seem to happen because given creates a lexical $_. It also happens
when
for/foreach is used with a lexical $_:Hmm what ? No, given does not create a lexical $_ :
I didn't look at the code only at the docs and the output :/
from perldoc perlsyn:
'given(EXPR) will assign the value of EXPR to $_ within the lexical scope of
the block, so it's similar to do { my $_ = EXPR; ... }'the output shows a different reference for $_ in the when block and in the
s1 subfrom pp_entergiven :
if (PL_op->op_targ == 0) {
SV ** const defsv_p = &GvSV(PL_defgv);
*defsv_p = newSVsv(POPs);
SAVECLEARSV(*defsv_p);
}
else
sv_setsv(PAD_SV(PL_op->op_targ), POPs);What happens, at first glance, it that List::Util always uses the
global $_. (an "our $_" in the "first" block should solve the pb).Then what does in create in pp_entergiven?
Doesn't it modify PL_defgv?
(I have to admit being not familiar enough with the code to really
read/understand it :( )Ah, you're right. The parser has this line :
switch : label GIVEN '(' remember mydefsv mexpr ')' mblock
where mydefsv is an empty rule that lexicalizes $_.
But then the code I pasted above could probably be simplified.Adding an our $_ does solve the problem:
With 's1 { our $_; print "\tblock:\t \$_ = " . \$_ . " (value: $_)"; };' the
output becomes:Given/when block:
when-1: $_ = SCALAR(0x942d7f0) (value: 1)
s1: $_ = SCALAR(0x942d500) (value: a)
block: $_ = SCALAR(0x942d500) (value: a)
when-2: $_ = SCALAR(0x942d7f0) (value: 1)But why is this be nessesary?
If given() does not create a lexical $_ then shouldn't the $_ in the block
be the same as the global $_?We provide UNDERBAR and dUNDERBAR macros to access the current $_, be
it lexical or global.However we don't have (yet) an API to localize the current $_ as
needed in grep-like functions.I suppose that code from pp_grepstart could be copied in List::Util to
solve the bug.That would only work for the XS version right?
(There is also a Pure Perl version...)Yes.
From @iabyn
On Tue, Jul 21, 2009 at 12:45:04PM +0200, Rafael Garcia-Suarez wrote:
Ah, you're right. The parser has this line :
switch : label GIVEN '(' remember mydefsv mexpr ')' mblock
where mydefsv is an empty rule that lexicalizes $_.
But then the code I pasted above could probably be simplified.So if I've understood this correctly, given() adds a lexical $_ to the
scope, and there's a bug in List::Util::first in that it doesn't work with
a lexical $_? So not a bug in given/smartmatch?use List::Util qw/first/;
print "ok outside\n" if first { $_ } 1;
{
my $_ = 0;
print "ok inside\n" if first { $_ } 1;
}outputs:
ok outside
--
Technology is dominated by two types of people: those who understand what
they do not manage, and those who manage what they do not understand.From p5p@perl.wizbit.be
Citeren Dave Mitchell <davem@iabyn.com>:
On Tue, Jul 21, 2009 at 12:45:04PM +0200, Rafael Garcia-Suarez wrote:
Ah, you're right. The parser has this line :
switch : label GIVEN '(' remember mydefsv mexpr ')' mblock
where mydefsv is an empty rule that lexicalizes $_.
But then the code I pasted above could probably be simplified.So if I've understood this correctly, given() adds a lexical $_ to the
scope, and there's a bug in List::Util::first in that it doesn't work with
a lexical $_? So not a bug in given/smartmatch?I'm not sure if 'bug' is the correct word.
What happens: (example with for instead of given)
#!/usr/bin/perl -l
for my $_ (1) {
my $c = sub { print $_ };
$c->();
}sub foo {
my $code = shift;
$_ = "abc";
$code->();
}
__END__$c is a closure and closes over $_.
It then passes the code reference to the function foo which modifies
the global $_ and calls the closure.But: the closure closes over $_ so it will always uses the value 1...
There are, as fas as I can see, two solutions:
1) modify given() so it doesn't use a lexical $_.
2) update the documentation for given() and make it more explicit that
it uses a lexical $_ and that every block/code reference inside it
needs our $_; before using $_.Best regards,
Bram
From @iabyn
On Fri, Jul 24, 2009 at 07:16:17PM +0200, Bram wrote:
Citeren Dave Mitchell <davem@iabyn.com>:
On Tue, Jul 21, 2009 at 12:45:04PM +0200, Rafael Garcia-Suarez wrote:
Ah, you're right. The parser has this line :
switch : label GIVEN '(' remember mydefsv mexpr ')' mblock
where mydefsv is an empty rule that lexicalizes $_.
But then the code I pasted above could probably be simplified.So if I've understood this correctly, given() adds a lexical $_ to the
scope, and there's a bug in List::Util::first in that it doesn't work with
a lexical $_? So not a bug in given/smartmatch?I'm not sure if 'bug' is the correct word.
Well,
use List::Util qw/first/;
{
my $_ = 0;
print "ok grep \n" if grep { $_ } 1;
print "ok first\n" if first { $_ } 1;
}outputs
ok grep
So, the behaviour of first() could be described as unexpected, to say the
least. I think the correct behaviour of first() would be to to modify the
$_ in the caller's scope rather than what's currently in scope.--
Nothing ventured, nothing lost.From @rgs
2009/7/24 Dave Mitchell wrote:
So if I've understood this correctly, given() adds a lexical $_ to the
scope, and there's a bug in List::Util::first in that it doesn't work with
a lexical $_? So not a bug in given/smartmatch?Yes, although I'm not 100% sure that pp_given does exactly the right
thing with the pad. List::Util::first needs to assign to the lexical $_
in the pad if there is one.--
The world is independent of my will.
-- Wittgenstein, Tractatus Logico-Philosophicus, 6.373From @rgs
2009/7/24 Rafael Garcia-Suarez <rgarciasuarez@gmail.com>:
2009/7/24 Dave Mitchell wrote:
So if I've understood this correctly, given() adds a lexical $_ to the
scope, and there's a bug in List::Util::first in that it doesn't work with
a lexical $_? So not a bug in given/smartmatch?Yes, although I'm not 100% sure that pp_given does exactly the right
thing with the pad. List::Util::first needs to assign to the lexical $_
in the pad if there is one.Yes, the patch below solves your reduced test case, the one with grep
and first, but doesn't solve the original problem, which denotes
probably another bug in pp_given (that constructs a lexical $_ without
a padmy op.)Graham, would you consider an improved version of the patch below for
List::Util, to make first work with lexical $_ ? I don't think there
are other areas in List::Util that need a similar modification.--- a/ext/List-Util/ListUtil.xs
+++ b/ext/List-Util/ListUtil.xs
@@ -329,16 +329,25 @@ CODE:
I32 gimme = G_SCALAR;
SV **args = &PL_stack_base[ax];
CV *cv;
+ PADOFFSET padoff_du = find_rundefsvoffset();
+ bool has_global_underbar = padoff_du == NOT_IN_PAD
+ || PAD_COMPNAME_FLAGS_isOUR(padoff_du);if(items <= 1) {
XSRETURN_UNDEF;
}
cv = sv_2cv(block, &stash, &gv, 0);
PUSH_MULTICALL(cv);
- SAVESPTR(GvSV(PL_defgv));
+ if (has_global_underbar)
+ SAVESPTR(GvSV(PL_defgv));
+ else
+ SAVESPTR(PAD_SVl(padoff_du));for(index = 1 ; index < items ; index++) {
- GvSV(PL_defgv) = args[index];
+ if (has_global_underbar)
+ GvSV(PL_defgv) = args[index];
+ else
+ PAD_SVl(padoff_du) = args[index];
MULTICALL;
if (SvTRUE(*PL_stack_sp)) {
POP_MULTICALL;From @ikegami
On Fri, Jul 24, 2009 at 4:42 PM, Rafael Garcia-Suarez <
rgarciasuarez@gmail.com> wrote:2009/7/24 Dave Mitchell wrote:
So if I've understood this correctly, given() adds a lexical $_ to the
scope, and there's a bug in List::Util::first in that it doesn't work
with
a lexical $_? So not a bug in given/smartmatch?Yes, although I'm not 100% sure that pp_given does exactly the right
thing with the pad. List::Util::first needs to assign to the lexical $_
in the pad if there is one.How are the Pure Perl implementation of List::Util and countless other Perl
(&) subs suppose to do that?From @ysth
On Fri, July 24, 2009 3:44 pm, Eric Brine wrote:
On Fri, Jul 24, 2009 at 4:42 PM, Rafael Garcia-Suarez <
rgarciasuarez@gmail.com> wrote:2009/7/24 Dave Mitchell wrote:
So if I've understood this correctly, given() adds a lexical $_ to
the scope, and there's a bug in List::Util::first in that it doesn't
work with
a lexical $_? So not a bug in given/smartmatch?Yes, although I'm not 100% sure that pp_given does exactly the right
thing with the pad. List::Util::first needs to assign to the lexical $_
in the pad if there is one.How are the Pure Perl implementation of List::Util and countless other
Perl (&) subs suppose to do that?Add a reference to the proper $_ to the caller() return list?
From @gbarr
On Jul 24, 2009, at 4:10 PM, Rafael Garcia-Suarez wrote:
Graham, would you consider an improved version of the patch below for
List::Util, to make first work with lexical $_ ? I don't think there
are other areas in List::Util that need a similar modification.Sure. first is the only place in List::Util where $_ is used. This
patch would work for the XS version, but what about the pure Perl ?Although should the code passed to first call a sub, that code will
not see $_, but I suspect grep has the same issue thereGraham.
--- a/ext/List-Util/ListUtil.xs
+++ b/ext/List-Util/ListUtil.xs
@@ -329,16 +329,25 @@ CODE:
I32 gimme = G_SCALAR;
SV **args = &PL_stack_base[ax];
CV *cv;
+ PADOFFSET padoff_du = find_rundefsvoffset();
+ bool has_global_underbar = padoff_du == NOT_IN_PAD
+ || PAD_COMPNAME_FLAGS_isOUR(padoff_du);if\(items \<= 1\) \{ XSRETURN\_UNDEF; \} cv = sv\_2cv\(block\, &stash\, &gv\, 0\); PUSH\_MULTICALL\(cv\);- SAVESPTR(GvSV(PL_defgv));
+ if (has_global_underbar)
+ SAVESPTR(GvSV(PL_defgv));
+ else
+ SAVESPTR(PAD_SVl(padoff_du));for\(index = 1 ; index \< items ; index\+\+\) \{- GvSV(PL_defgv) = args[index];
+ if (has_global_underbar)
+ GvSV(PL_defgv) = args[index];
+ else
+ PAD_SVl(padoff_du) = args[index];
MULTICALL;
if (SvTRUE(*PL_stack_sp)) {
POP_MULTICALL;From @ysth
On Fri, July 24, 2009 5:28 pm, Yitzchak Scott-Thoennes wrote:
On Fri, July 24, 2009 3:44 pm, Eric Brine wrote:
On Fri, Jul 24, 2009 at 4:42 PM, Rafael Garcia-Suarez wrote:
Yes, although I'm not 100% sure that pp_given does exactly the right
thing with the pad. List::Util::first needs to assign to the lexical
$_ in the pad if there is one.How are the Pure Perl implementation of List::Util and countless other
Perl (&) subs suppose to do that?Add a reference to the proper $_ to the caller() return list?
Err, never mind, that wouldn't tell you what $_ was in scope of the sub if
the sub wasn't in the caller's scope.11 remaining items
From @cpansprout
On Sat Dec 10 15:42:18 2011, perl.p5p@rjbs.manxome.org wrote:
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2011-12-
10T14:51:53]RJBS: Would you be adverse to changing ‘given’ to alias $_ properly,
or
is it too close to 5.16 at this stage?I agree, *strenuously* that 'given' is a big problem on several
fronts, and the
lexical $_ is certainly one of the more widely-felt pains.I think fixing it via something like :5.16 containing given5_16 is not
nuts,
but I've got to say: I think we should be considering deprecating
given for
straight-up removal.From a maintenance standpoint, +1000! But I am loath to break anyone’s
code. On the other hand, it has only been a short while since it was
introduced, and almost everyone who has tried it has run into problems.
So I won’t get in the way of its removal.In the meantime, would we want to consider warning on closing over
lexical $_
inside a given?Absolutely.
Does anybody ever do this on purpose?
I doubt it.
--
Father Chrysostomos
From @xdg
On Sat, Dec 10, 2011 at 6:41 PM, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:I agree, *strenuously* that 'given' is a big problem on several fronts, and the
lexical $_ is certainly one of the more widely-felt pains.I think fixing it via something like :5.16 containing given5_16 is not nuts,
but I've got to say: I think we should be considering deprecating given for
straight-up removal.I'm supportive only if we replaced it with a decent switch construct
or deprecated just the broken parts of it. It doesn't have to be a
"smart" switch -- just a switch against scalars would be fine. (Nit
-- I suppose the challenge is numeric or string matching -- maybe a
"numeric $scalar" or "string $scalar" keyword like "scalar" for that
context?) For anything "smart", we can/should use if/elsif.In the meantime, would we want to consider warning on closing over lexical $_
inside a given? Does anybody ever do this on purpose?A warning sounds reasonable and anyone doing it on purpose can turn
off the warning.-- David
From chris@prather.org
I missed the list (my apologies David).
-Chris
---------- Forwarded message ----------
From: Chris Prather <chris@prather.org>
Date: Sat, Dec 10, 2011 at 10:13 PM
Subject: Re: [perl #105850] $_ does not work as expected within "given" block
To: David Golden <xdaveg@gmail.com>On Sat, Dec 10, 2011 at 7:52 PM, David Golden <xdaveg@gmail.com> wrote:
On Sat, Dec 10, 2011 at 6:41 PM, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:I agree, *strenuously* that 'given' is a big problem on several fronts, and the
lexical $_ is certainly one of the more widely-felt pains.I think fixing it via something like :5.16 containing given5_16 is not nuts,
but I've got to say: I think we should be considering deprecating given for
straight-up removal.I'm supportive only if we replaced it with a decent switch construct
or deprecated just the broken parts of it. It doesn't have to be a
"smart" switch -- just a switch against scalars would be fine. (Nit
-- I suppose the challenge is numeric or string matching -- maybe a
"numeric $scalar" or "string $scalar" keyword like "scalar" for that
context?) For anything "smart", we can/should use if/elsif.Switch and Smart Matching are not equivalent.
I'm guessing (hoping?) that Ric is simply talking about deprecating
`given` and not `when`. Which would leave the more Perl5-ish:for ($var) {
when (defined) { ... }
when (m/foo/) { ... }
when ($_ eq 'bar') { ... }
}That is all you need for switch is a topicalizer (for) and a test that
exits the block on success (when). These cover 99% of the use cases
I've seen in the wild for given/when.Fact is that I try very hard to only use given/when in cases where I
know it fits within one of the special cases (see above). Removing
given() wouldn't be that painful to most of the code I'm responsible
for, nor honestly would removing SmartMatch. Removing when() however
would make me cry.In the meantime, would we want to consider warning on closing over lexical $_
inside a given? Does anybody ever do this on purpose?A warning sounds reasonable and anyone doing it on purpose can turn
off the warning.no warnings "given"; # none 'expected';
:)
-Chris
From @Leont
On Sun, Dec 11, 2011 at 12:41 AM, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:I agree, *strenuously* that 'given' is a big problem on several fronts, and the
lexical $_ is certainly one of the more widely-felt pains.I think fixing it via something like :5.16 containing given5_16 is not nuts,
but I've got to say: I think we should be considering deprecating given for
straight-up removal.In the meantime, would we want to consider warning on closing over lexical $_
inside a given? Does anybody ever do this on purpose?It's possible to do the right thing AFAIK, it's just that no one does
it. Ironically, it's quite easy and sane to do in XS, but really hard
in pure perl. I'd like a way to flag a function as being able to
handle lexical $_ if we are going to make this warn.Leon
From @cpansprout
On Sun Dec 11 06:05:24 2011, LeonT wrote:
On Sun, Dec 11, 2011 at 12:41 AM, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:I agree, *strenuously* that 'given' is a big problem on several
fronts, and the
lexical $_ is certainly one of the more widely-felt pains.I think fixing it via something like :5.16 containing given5_16 is
not nuts,
but I've got to say: I think we should be considering deprecating
given for
straight-up removal.In the meantime, would we want to consider warning on closing over
lexical $_
inside a given? �Does anybody ever do this on purpose?It's possible to do the right thing AFAIK, it's just that no one does
it. Ironically, it's quite easy and sane to do in XS, but really hard
in pure perl. I'd like a way to flag a function as being able to
handle lexical $_ if we are going to make this warn.What’s so ironic is that, if called functions can see it, $_ isn’t
really lexical any more, is it?--
Father Chrysostomos
From @rjbs
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2011-12-11T09:48:24]
On Sun Dec 11 06:05:24 2011, LeonT wrote:
It's possible to do the right thing AFAIK, it's just that no one does
it. Ironically, it's quite easy and sane to do in XS, but really hard
in pure perl. I'd like a way to flag a function as being able to
handle lexical $_ if we are going to make this warn.given ($x) {
no warnings 'closure';
my $sub = sub { warn $_ };
}Something along those lines?
What’s so ironic is that, if called functions can see it, $_ isn’t
really lexical any more, is it?Well, they're seeing it because they closed over it, right? That's still
lexical.--
rjbsFrom @cpansprout
On Mon Dec 12 12:20:53 2011, perl.p5p@rjbs.manxome.org wrote:
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2011-12-
11T09:48:24]On Sun Dec 11 06:05:24 2011, LeonT wrote:
It's possible to do the right thing AFAIK, it's just that no one
does
it. Ironically, it's quite easy and sane to do in XS, but really
hard
in pure perl. I'd like a way to flag a function as being able to
handle lexical $_ if we are going to make this warn.given ($x) {
no warnings 'closure';
my $sub = sub { warn $_ };
}Something along those lines?
I think Leon Timmermans meant that functions like Scalar::Util::first
should be able to suppress that warning in their *arguments*.given ($x) {
when(first { ... $_ ... }); # no warning
when(other_func { ... $_ ... }); # warning
}What’s so ironic is that, if called functions can see it, $_ isn’t
really lexical any more, is it?Well, they're seeing it because they closed over it, right? That's
still
lexical.I’m referring to the ability of XS modules (like Scalar::Util::first) to
access the lexical $_ of the caller. Scalar::Util::first doesn’t
actually do that, so it’s not a good example, but there is an API for it.--
Father Chrysostomos
From @Leont
On Mon, Dec 12, 2011 at 10:03 PM, Father Chrysostomos via RT
<perlbug-followup@perl.org> wrote:I think Leon Timmermans meant that functions like Scalar::Util::first
should be able to suppress that warning in their *arguments*.given ($x) {
when(first { ... $_ ... }); # no warning
when(other_func { ... $_ ... }); # warning
}Exactly.
I’m referring to the ability of XS modules (like Scalar::Util::first) to
access the lexical $_ of the caller. Scalar::Util::first doesn’t
actually do that, so it’s not a good example, but there is an API for it.Though I'm not sure any module uses it currently TBH, ppport and some
unicode symbols generate too much noise for grep.cpan.me to give clear
results but I didn't see any positives so far.Leon
From @cpansprout
Fixed by b5a6481.
@cpansprout - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#67694 (status was 'resolved')
Searchable as RT67694$