> On Nov 22, 2021, at 09:46, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
> On Mon, Nov 22, 2021, at 1:42 AM, Tom Molesworth wrote:
>> On Mon, 22 Nov 2021 at 05:13, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>
>> I propose that as soon as possible, we update signatured subroutines so that…
>> • when a subroutine has a signature, the @_ variable is not populated when the subroutine is entered
>> Why delay stable signatures for an optimisation like this, particularly one that could be achieved by a compile-time "if @_ is seen in the body, populate it, otherwise we can leave it out" check?
>
> This topic was discussed extensively in the past, but in part boils down to: "You can't tell well enough at compile time."
>
>> • "Accessing @_ in a subroutine that has a signature is meaningless".
>> This is incorrect. For example:
>
> It would be meaningless under this proposal because we would strip the meaning from it.
>
> We can ship, together with or later than no-@_-signatured-subroutines, a means to check the argc of the current call, like caller->argc or builtin::current_sub_call_arg_count or the like.
>
> Signatured subroutines don't need to provide every possible feature of non-signatured subroutines, especially out of the gate. They are, I assert, valuable enough as sugar, even if sometimes you have to bypass them and write the lower-level form. Also, we can make fewer things require bypassing as time goes on.
Somewhat off-topic: What is the speed advantage of suppressing @_ in a sigged sub?
If speed is a palpable advantage then that’s a huge win because then the announcement is: “Not only are signatures safe, but they’re faster than your old code!”
-F
>
> On Mon, Nov 22, 2021, at 1:42 AM, Tom Molesworth wrote:
>> On Mon, 22 Nov 2021 at 05:13, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>
>> I propose that as soon as possible, we update signatured subroutines so that…
>> • when a subroutine has a signature, the @_ variable is not populated when the subroutine is entered
>> Why delay stable signatures for an optimisation like this, particularly one that could be achieved by a compile-time "if @_ is seen in the body, populate it, otherwise we can leave it out" check?
>
> This topic was discussed extensively in the past, but in part boils down to: "You can't tell well enough at compile time."
>
>> • "Accessing @_ in a subroutine that has a signature is meaningless".
>> This is incorrect. For example:
>
> It would be meaningless under this proposal because we would strip the meaning from it.
>
> We can ship, together with or later than no-@_-signatured-subroutines, a means to check the argc of the current call, like caller->argc or builtin::current_sub_call_arg_count or the like.
>
> Signatured subroutines don't need to provide every possible feature of non-signatured subroutines, especially out of the gate. They are, I assert, valuable enough as sugar, even if sometimes you have to bypass them and write the lower-level form. Also, we can make fewer things require bypassing as time goes on.
Somewhat off-topic: What is the speed advantage of suppressing @_ in a sigged sub?
If speed is a palpable advantage then that’s a huge win because then the announcement is: “Not only are signatures safe, but they’re faster than your old code!”
-F