Front page | perl.perl5.porters |
Postings from June 2013
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! :-) -- Father Chrysostomos --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=118691Thread Previous | Thread Next