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

Re: PSC #049 2022-01-07

Thread Previous | Thread Next
Ovid via perl5-porters
January 9, 2022 13:28
Re: PSC #049 2022-01-07
Message ID:
On Sunday, 9 January 2022, 13:38:07 CET, Neil Bowers <> wrote:

> 1. Remove the experimental sticker off signatures and release that way in 5.36 (so you'd still have to `use feature` or `use v5.36`), but no other changes.  
> 2. As for 1, but also add a runtime warning if you touch @_ inside a signatured-sub.
> 3. Like 2, but touching @_ is fatal.
> 4. Inside signatured-subs @_ becomes non-special.

I dislike #1 because that will drag out the @_ issue. if someone needs it, they can always use `sub foo (@args) {...}`

I dislike #3 and #4 (if I understand your intent) because that will break existing code, requiring more work for maintainers. They can't just enable/disable things. They have to rewrite code (again, assuming I am understanding correctly).

#2 seems to be to clearest path forward to removing this feature altogether.

Would there be a warnings category for disabling @_ warnings? Something like (no idea what to call it):

    no warnings "deprecated::args_array";

With that, we could silence that single warning, but it's easy to grep through a codebase for deprecated features. In fact, I'd love to see tons more deprecated warning categories to make it easier to track them in larger codebases. We have clients who could probably use something like this.

IT consulting, training, specializing in Perl, databases, and agile development 

Buy my book! -

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