develooper Front page | perl.perl5.porters | Postings from January 2022

Re: PSC #049 2022-01-07

Thread Previous | Thread Next
Paul "LeoNerd" Evans
January 16, 2022 11:58
Re: PSC #049 2022-01-07
Message ID:
On Sun, 16 Jan 2022 12:23:53 +0100
demerphq <> wrote:

> Hrm, it seems like that would be solution so rjbs could have what he
> thinks is sensibel, and you could have what you think is sensible.
> If one could introspect on the arity of a sub then to some level this
> could be avoided. Eg, when the new framework accepts a sub designed
> for the old 1 argument API, it could internally ensure that  sub was
> called with 1 argument, and call the subs intended for more than 1
> argument as required. If you can't introspect on the arity then you
> can not harden yourself for this. Eg, a forward looking dev could say
> "my callback framework insists the callback accepts a slurpy argument
> list" and warn or die when someone passes in one that doesnt have
> artiy==-1 (-1 for infinity), and one less prescient could do
> something else internally, something like:
> my $arity=arity($sub_ref);
> if ($arity == 1) {
>   $sub_ref->($key)
> }
> elsif ($arity < 0 or $arity == 2 ) {
>   $sub_ref->($key,$index);
> }


> Personally I cant understand why if perl can validate the arity of a
> sub we cannot provide a mechanism to determine what that is at a code
> level.

> While in this new PSC world I dont believe my opinion matters much,
> it at all, I personally think you have case to go to rjbs and the PSC
> and say, "I do not want to change the rules about arity, but I *do*
> think we should provide a way to introspect on it", and I think rjbs
> might be a bit more amenable to talk about it if he understand it
> wasnt the "bypass arity checks" argument rehashed. I dont him that
> well, and we do disagree from time to time, but IMO he is usually a
> pretty reasonable guy.

((With my personal hat and not my PSC hat))

I've also been wanting (needing) an arity-inspection mechanism,
currently required to make Syntax::Keyword::MultiSub work.

Also in the presence of such a mechanism it would be possible to write
a little call-wrapper to call a sub with no more arguments than it was
expecting, even if I accept that it will *SILENTLY* discard extra ones:

  sub call_no_arity ($code, @args) {
    my $nmax = max_arity_of $code;
    splice @args, $nmax, -1, () if defined $nmax;
    return $code->(@args);


  sub each ($code) {
    call_no_arity $code, $item, $index, $context;

Could be used with any of the following, without error:

  ->each(sub ($item) { ... });
  ->each(sub ($item, $idx) { ... });
  ->each(sub ($item, $idx, $c) { ... });

That said, my ideal wish would be for arity-checking to appear as a
default-fatal exception from the caller's perspective; so the caller
could do something like:

  sub each ($code) {
      no fatal 'signatures::max_arity';
      $code->($item, $index, $context);

To, within that small lexical scope, disarm the fatality of maximum
arity checking.

Paul "LeoNerd" Evans      |  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About