Front page | perl.perl5.porters |
Postings from December 2021
On Thu, 9 Dec 2021 18:47:38 +0000 Dave Mitchell <davem@iabyn.com> wrote: > On Thu, Dec 09, 2021 at 01:41:29PM -0500, Felipe Gasper wrote: > > > > 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. No, we can't remove it. First of all, signatures are experimental pretty much only on paper. We dragged our feet for too long, our users grew impatient and now *lots* of codebases are using them in production. Breakage like this will make people angry. Also, even if backwards compatibility wasn't a concern, not having working stacktraces is still completely unacceptable.Thread Previous | Thread Next