On Fri, Sep 02, 2011 at 04:35:57PM +0200, Mark Overmeer wrote: > * Abigail (abigail@abigail.be) [110902 14:08]: > > I don't think "needs a scalar" actually means "will not accept an > > array as argument". > > > > In fact, I consider the bug here to be: > > $ perl -wE '@a = 2; exit @a; echo $?' > > 1 > > But an array is not a scalar! An array is NOT the same thing as a > list of scalars. And yet, we keep telling, and proud ourselves that argument lists are flattened in Perl. And, yes, I know there's a difference in the face of prototypes. Which, IMO, make prototypes a huge big pain in the ass with little benefits. Joe the average programmer doesn't realize this. But all of that is irrelevant. Your claim was that it's documented as "needs a scalar". It 1) isn't, and 2) it's an ambiguous term anyway. > > I actually expect this to print 2, and checking the manual page for exit, > > there's actually nothing in it that suggests it's evaluating its argument > > list in scalar context. Not only doesn't it say "needs a scalar", it doesn't > > even mention the word "scalar": > > > > =item exit > > Evaluates EXPR and exits immediately with that value. > > IMO, a "value" is not the same as "the first value of a list/array" > So documented is that EXPR is expected to produce a single thing, > which @x in POSIX::exit(@x) can only be if there is a prototype. > > OK, but that point has been raised a few times before. Can you also > give your response to my counter argument that it is very unpleasant > when > > use POSIX 'exit'; > ... zillion lines of code ... > exit(@x) > > differs from > > ... zillion lines of code ... > exit(@x) > > Or even worse, with functions with a single scalar which change from > being prefix operator priority into functions by a seemingly unrelated > "use" statement... Of course, this is only a problem when you do not > use parens for function calls (I like to have few parens, and Perl > allows me to) Whether it's unpleasant or not is an argument that should have been raised when POSIX.pm was introduced (or when prototypes were added to the core, whatever happened last). What's important now is, "do we want to break backwards compatability". I'm with Nick on this one. First, I don't expect "exit (@x)" is used often. Second, since "POSIX::exit(@x)" does DWIM, and "exit(@x)" doesn't, I don't see any benefits on make neither DWIM. Third, who's going to benefit? Is potentially breaking existing, working code worth the benefit of "some new code that uses an odd construct, now behaves equally unexpected regardless whether POSIX is present"? IMO, the benefit doesn't outweight the downside. AbigailThread Previous | Thread Next