Front page | perl.perl5.porters |
Postings from June 2013
On 06/30/2013 08:03 AM, Father Chrysostomos via RT wrote: > On Sun Jun 30 05:37:19 2013, jkeenan wrote: >> On Sat Jun 29 10:13:54 2013, sprout wrote: >>> On Sat Jun 29 08:06:12 2013, jkeenan wrote: >>>> Your fourth call is not equivalent to your third call. There's no > '//' >>>> operator imposing a context on $array[-1]. Perl looks at that > variable >>>> directly and notes that it runs afoul of the error condition described >>>> above. You're asking for $array[-1] to spring to life. I'm sure that >>>> there are others who can explain better than I can why we treat > that as >>>> a fatal error -- but fatal it is nonetheless. >>> >>> Whether this is a bug or no, it is certainly surprising--and fixable. >>> >> >> I think what is more surprising is that the poster's second and fourth >> cases behave differently, i.e., that func($array[0]) has at least the >> appearance of being well-behaved, > > That is a feature, added by 68dc07451. One can pass nonexistent > elements to functions without having them vivified immediately. Only > when $_[0] is modified inside the function is the element vivified. > >> whereas func($array[-1] generates a >> fatal error. >> >>> It’s just a matter of tweaking the defer logic in pp_aelem. Then rvalue >>> uses of $_[0] within the function will just work, but assignment to >>> $_[0] will croak with the same error (i.e., the error will be delayed as >>> long as possible). >>> >> >> Do we really want to do that? > > I say Yes! :-) > +1Thread Previous