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

Re: PSC #049 2022-01-07

Thread Previous | Thread Next
Yuki Kimoto
January 17, 2022 00:03
Re: PSC #049 2022-01-07
Message ID:
2022-1-17 4:15 Ricardo Signes <> wrote:

> On Sun, Jan 16, 2022, at 6:23 AM, demerphq wrote:
> 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.
> I don't mind the existence of a "Sub::Util::arity_of" or something.  (I'm
> not sure what return would be best, since it needs to handle:
>    - undeclared
>    - fixed number
>    - n or more
>    - n or more, but even/odd)
> What I don't want is to change the behavior we have out of the box, or to
> further delay shipping this based on something that can be added in the
> future.
> I am going to CC him on this, he can yell at me if he wants. :-)
> I mean, I read p5p, which got all the previous messages, too. 😉  I will
> only yell if you spill my beer.
> --
> rjbs

 I have the same thinking as Tom about possible accidents.

My proposal makes arity checking optional.

  use feature 'no_arity_check';

- Don't break anything, including experimental ones.
- Users can bypass arity checks. This is convenient because users can
rewrite the existing codes using signatures without changing any behavior.
- If we want to implement multi-sub in the future, use subroutines that the
arity checking is enabled.
- Subroutine arguments are used by everyone, so it should be selectable.
Coexistence of those who like arity checking and those who do not.
- There is no need to postpone the release of the current signatures.
- This way is very easy. Remove only ops of "... if @_> ..." "... if @ <
..." and "... if @_ % 2 != 0" when enabling "no_arity_check"
- A little faster  than with arity checking.

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