Front page | perl.perl5.porters |
Postings from January 2022
Re: PSC #049 2022-01-07
Thread Previous
|
Thread Next
From:
Yuki Kimoto
Date:
January 17, 2022 00:03
Subject:
Re: PSC #049 2022-01-07
Message ID:
CAExogxPvNXVb8YQ_8BC5yt2u3i7uDm0CNxLFOEcCC_pkLkTBZQ@mail.gmail.com
2022-1-17 4:15 Ricardo Signes <rjbs@cpan.org> 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