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

Re: arity checking (was Re: PSC #049 2022-01-07)

Thread Previous | Thread Next
Tom Molesworth via perl5-porters
January 21, 2022 18:20
Re: arity checking (was Re: PSC #049 2022-01-07)
Message ID:
On Sat, 22 Jan 2022 at 01:49, Dave Mitchell <> wrote:

> On Fri, Jan 21, 2022 at 06:29:27PM +0100, demerphq wrote:
> > So consider, I own a framework whose api is that I accept a callback from
> > the caller. I tell the caller that my api will call his sub with 1
> > argument, lets say "key".
> There's the crunch. If your framework promises to call always with one
> arg, then if you call the callback with 2 args, you've broken your
> promise.

Do you have examples of such frameworks, where there's an explicit promise
of never adding more args? (rather than saying "this takes 1 argument" with
"at the moment" being implicit)

If those exist, I believe those are the exception, rather than the norm.

Anyway, this thread seems to be repeating what was discussed very recently
- see
for an example use-case.

Your eval workaround assumes that the directly-called sub is the only
possible thing which can throw the exception - what if that's triggered by
a sub further down?

I ended up writing
as a proof-of-concept API, but would hope that core Perl will expose some
sort of arity inspection in due course. Ignoring this library-extensibility
use-case while simultaneously promoting signatures as a complete
replacement for @_-based subs seems less than ideal to me.

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