Re: Contents of @_ using subroutine signatures with default values

[dave_the_m]

One reason why signatures are still marked as experimental is that in a future release or perl, @_ probably wont be populated within signatured subroutines

Dave.

[LanX]

> @_ probably wont be populated within signatured subroutines

This desire seems to originate from the performance impact of populating @_.

But this will break some compatibility to older code and make migration harder.

May I suggest a compromise to scan the functions body for the use of @_ and to dynamically decide then?

Attaching a flag to the code-ref which is evaluated by the signature code once the parser encounters @_ shouldn't be too difficult.

I hope you all have in mind that goto &sub relies on @_.

So does the debugger via @DB:_ for call stack traces.

As a side note: JS has a "arguments" array analog to @_ and performance is not JS' problem.

[dave_the_m]

The simplified answer: no, it's not that simple. If @_ isn't populated, then the signature code gets its arguments directly from the stack. If @_ gets populated, then the stack and @_ can get out of sync, e.g. by code within the signature which manipulates @_. So in that case the code must get its args from @_ rather than from the stack. So there have to be two code paths for everything.

See this p5p post for more details.

Dave.

[LanX]

> See this p5p post for more details.

Thanks Dave, I will.

... this will be a longer read this evening. OO

On a side note: I was fascinated to learn (rediscover ?), that a call &sub without arguments has full access to the callers @_.

use strict;
use warnings;
use Data::Dump qw/pp dd/;


sub foo {
    warn pp \@_;
    push @_,@_+1
}

sub tst {
    &foo;
    &foo;
    &foo;
    warn pp \@_;
}

tst(1);

 
-*- mode: compilation; default-directory: "d:/exp/" -*-
Compilation started at Tue Jul 14 12:21:10

C:/Perl_524/bin\perl.exe -w d:/exp/access_@_.pl 
[1] at d:/exp/access_@_.pl line 7.
[1, 2] at d:/exp/access_@_.pl line 7.
[1, 2, 3] at d:/exp/access_@_.pl line 7.
[1 .. 4] at d:/exp/access_@_.pl line 15.

Compilation finished at Tue Jul 14 12:21:10

[perlfan]

> @_ probably wont be populated

I think it is important to note that shift is also destructive, so using that as the idiomatic control of the experimental feature shows that processing it the accepted way more often than not also results in @_ not being populated.

This doesn't apply to another idiom (that I even use some times) that are non-destructive - like, my %opts = @_ - assuming params are passed in like foo(param1 => 2, param2 => 'foo').

[1nickt]

FWIW I certainly hope this comes true.