[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl5-porters
Subject:    [perl #78288] ref and other ops are inefficient in boolean context
From:       "Father Chrysostomos via RT" <perlbug-followup () perl ! org>
Date:       2017-07-28 17:09:09
Message-ID: rt-4.0.24-7968-1501261748-1307.78288-15-0 () perl ! org
[Download RAW message or body]

On Fri, 28 Jul 2017 04:35:26 -0700, davem wrote:
> On Thu, Jul 27, 2017 at 04:22:47PM -0700, Father Chrysostomos via RT wrote:
> > On Thu, 27 Jul 2017 16:14:18 -0700, sprout wrote:
> > > On Thu, 27 Jul 2017 03:50:56 -0700, davem wrote:
> > > > A downside of &PL_sv_zero is that if assigned to a variable, that
> > > > variable
> > > > gets int, num and string values rather than just an int value.
> > > 
> > > Why does that need to be the case?  Why cannot PL_sv_zero have just
> > > the SvIOK flag on?
> 
> because the first time you do, e.g.
> 
>     @a=();
>     say "size=" . @a;
> 
> PL_sv_zero gets upgraded to an SvPOK() PVIV  anyway.
> 
> > > Does it matter that \(%h && $foo) now returns a reference to a read-
> > > only value when %h is empty?  (If so, that can be solved by turning on
> > > PADTMP on PL_sv_zero.)
> > 
> > I think it does matter.  grep(1,@list_with_one_item) returning a mutable
> > 1 and grep(1,@list_with_zero_items) returning a read-only variable is
> > the kind of icky inconsistency that I tried hard to eliminate.
> 
> Won't setting PADTMP cause PL_sv_zero's PVX buffer to be stolen? Or is
> that not done on a R/O var?

It is not done on a R/O var.


-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=78288
[prev in list] [next in list] [prev in thread] [next in thread]