develooper Front page | perl.perl5.porters | Postings from December 2021

Re: "no snails"; or having signatured subs complain about @_

Thread Previous | Thread Next
From:
Tomasz Konojacki
Date:
December 9, 2021 19:43
Subject:
Re: "no snails"; or having signatured subs complain about @_
Message ID:
20211209204311.B8DA.5C4F47F8@xenu.pl
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About