On Thu, Dec 09, 2021 at 01:41:29PM -0500, Felipe Gasper wrote: > > > On Dec 9, 2021, at 13:37, Dave Mitchell <davem@iabyn.com> wrote: > > > > On Thu, Dec 09, 2021 at 05:36:06PM +0000, Paul "LeoNerd" Evans wrote: > >> This was the problem though - I couldn't work out how to keep @DB::args > >> working in that situation. > > > > A more radical proposition would be to declare that @DB::args will always > > return empty for signature subs. > > Would that break stack traces--or at least the argument-listing part of > them? Yes. > If so, that would seem to be an unfortunate disincentive to adopt signatures. Here's the current disclaimer in caller()'s pod: Be aware that setting C<@DB::args> is I<best effort>, intended for debugging or generating backtraces, and should not be relied upon. In particular, as L<C<@_>|perlvar/@_> contains aliases to the caller's arguments, Perl does not take a copy of L<C<@_>|perlvar/@_>, so C<@DB::args> will contain modifications the subroutine makes to L<C<@_>|perlvar/@_> or its contents, not the original values at call time. C<@DB::args>, like L<C<@_>|perlvar/@_>, does not hold explicit references to its elements, so under certain cases its elements may have become freed and reallocated for other variables or temporary values. Finally, a side effect of the current implementation is that the effects of C<shift @_> can I<normally> be undone (but not C<pop @_> or other splicing, I<and> not if a reference to L<C<@_>|perlvar/@_> has been taken, I<and> subject to the caveat about reallocated elements), so C<@DB::args> is actually a hybrid of the current state and initial state of L<C<@_>|perlvar/@_>. Buyer beware. @DB::args should never have been added. This gives us a chance to remove it without breaking backwards compatibility. -- A major Starfleet emergency breaks out near the Enterprise, but fortunately some other ships in the area are able to deal with it to everyone's satisfaction. -- Things That Never Happen in "Star Trek" #13Thread Previous | Thread Next