Skip Menu |

Subject: & prototype is too permissive
Download (untitled) / with headers
text/plain 812b
According to perlsub, ‘An "&" requires an anonymous subroutine, which, if passed as the first argument, does not require the "sub" keyword or a subsequent comma.’ In actuality, it also allows ‘undef’, \@array, \%hash, \&sub, and \($list, @of, %refs) in addition to sub{...}. Recently I accidentally extended it to \$scalar as well, so I want to undo that accidental change and make it more restrictive. The way the code is written suggests to me that undef was intentional but \@array and \%hash (and maybe even \&sub) were accidentaly. But \&sub seems useful, and that may be in use already on CPAN. \@array and \%hash were clearly accidental, and lists of refs screw up the number of arguments that the sub thinks its getting. So should I allow sub{}, undef, and \&sub? -- Father Chrysostomos
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Subject: Re: [perl #123062] & prototype is too permissive
Date: Sun, 23 Nov 2014 17:05:44 -0500
Download (untitled) / with headers
text/plain 933b
* Father Chrysostomos <perlbug-followup@perl.org> [2014-10-26T15:40:50] Show quoted text
> The way the code is written suggests to me that undef was intentional but > \@array and \%hash (and maybe even \&sub) were accidentaly. But \&sub seems > useful, and that may be in use already on CPAN. \@array and \%hash were > clearly accidental, and lists of refs screw up the number of arguments that > the sub thinks its getting. > > So should I allow sub{}, undef, and \&sub?
I think \&sub should stay. It Just Makes Sense™. Putting aside that the code looks intentional, why do you suppose undef would be allowed? That is: why would that intention have existed? I'd have expected it would be much more consitent for it to act like \@. There may be more harm in forbidding undef, or making a warning, but I'm curious as to why this would've been done on purpose. I'd look into blame, but my timer is now telling me to start dinner. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Sun Nov 23 14:06:08 2014, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> * Father Chrysostomos <perlbug-followup@perl.org> [2014-10- > 26T15:40:50]
> > The way the code is written suggests to me that undef was intentional > > but > > \@array and \%hash (and maybe even \&sub) were accidentaly. But > > \&sub seems > > useful, and that may be in use already on CPAN. \@array and \%hash > > were > > clearly accidental, and lists of refs screw up the number of > > arguments that > > the sub thinks its getting. > > > > So should I allow sub{}, undef, and \&sub?
> > I think \&sub should stay. It Just Makes Sense™. > > Putting aside that the code looks intentional, why do you suppose > undef would > be allowed? That is: why would that intention have existed?
I don’t know. Maybe it was just a mistake. But the code clearly checks for refgen or undef, and croaks on anything else. Refgen allows sub{} and \&sub, but also other things as I detailed above, so that check is clearly not sufficient. But undef? Who knows! Show quoted text
> I'd have > expected > it would be much more consitent for it to act like \@.
Same here. Show quoted text
> There may be more harm in forbidding undef, or making a warning,
Maybe it’s not too late (in the dev cycle) to change it now and see whether anything breaks. It clearly contradicts the documentation. Show quoted text
> but > I'm > curious as to why this would've been done on purpose. I'd look into > blame, but > my timer is now telling me to start dinner.
You have to dig through a few layers, but explicit ‘allow refgen or undef’ goes back to: commit 4633a7c4bad06b471d9310620b7fe8ddd158cccd Author: Larry Wall <lwall@scalpel.netlabs.com> Date: Tue Nov 21 10:01:00 1995 +1200 5.002 beta 1 If you ‘git show 4633a7c4:Changes’ and search for ‘added rudimentary prototypes’ you will see the description, but it says even less than perlsub already says on the topic. -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Sun Nov 23 16:01:38 2014, sprout wrote: Show quoted text
> On Sun Nov 23 14:06:08 2014, perl.p5p@rjbs.manxome.org wrote:
> > * Father Chrysostomos <perlbug-followup@perl.org> [2014-10- > > 26T15:40:50]
> > > The way the code is written suggests to me that undef was > > > intentional > > > but > > > \@array and \%hash (and maybe even \&sub) were accidentaly. But > > > \&sub seems > > > useful, and that may be in use already on CPAN. \@array and \%hash > > > were > > > clearly accidental, and lists of refs screw up the number of > > > arguments that > > > the sub thinks its getting. > > > > > > So should I allow sub{}, undef, and \&sub?
> > > > I think \&sub should stay. It Just Makes Sense™. > > > > Putting aside that the code looks intentional, why do you suppose > > undef would > > be allowed? That is: why would that intention have existed?
> > I don’t know. Maybe it was just a mistake. But the code clearly > checks for refgen or undef, and croaks on anything else. Refgen > allows sub{} and \&sub, but also other things as I detailed above, so > that check is clearly not sufficient. But undef? Who knows! >
> > I'd have > > expected > > it would be much more consitent for it to act like \@.
> > Same here. >
> > There may be more harm in forbidding undef, or making a warning,
> > Maybe it’s not too late (in the dev cycle) to change it now and see > whether anything breaks. It clearly contradicts the documentation.
I’ve changed it in e41e9865be. I’m hoping that the amount of breakage will be zilch, because of that contradiction. -- Father Chrysostomos
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
Date: Mon, 24 Nov 2014 12:45:09 -0500
Subject: Re: [perl #123062] & prototype is too permissive
CC: ;, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 237b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-11-23T23:42:23] Show quoted text
> I’ve changed it in e41e9865be. I’m hoping that the amount of breakage will > be zilch, because of that contradiction.
Cool, I hope so, too. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 422b
On Mon Nov 24 09:45:52 2014, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-11- > 23T23:42:23]
> > I’ve changed it in e41e9865be. I’m hoping that the amount of > > breakage will > > be zilch, because of that contradiction.
> > Cool, I hope so, too.
We have one instance of breakage here: https://rt.cpan.org/Ticket/Display.html?id=101064 -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 527b
On Sun Dec 21 07:20:48 2014, sprout wrote: Show quoted text
> On Mon Nov 24 09:45:52 2014, perl.p5p@rjbs.manxome.org wrote:
> > * Father Chrysostomos via RT <perlbug-followup@perl.org> [2014-11- > > 23T23:42:23]
> > > I’ve changed it in e41e9865be. I’m hoping that the amount of > > > breakage will > > > be zilch, because of that contradiction.
> > > > Cool, I hope so, too.
> > We have one instance of breakage here: > https://rt.cpan.org/Ticket/Display.html?id=101064
I have created ticket #123475 for that. -- Father Chrysostomos


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org