On 2012-06-26 demerphq wrote: > On 25 June 2012 22:51, Father Chrysostomos via RT > <perlbug-followup@perl.org> wrote: > > Allowing an empty list provides a clear benefit and makes things > > more consistent. What problems could it cause? > > It would make debugging difficult. Consider generated code, etc. How would it make debugging more difficult? > I am with Reini on this one, and ill drag in Larry too. Im pretty sure > if Larry thought that > > my (); > > should be legal it already would be. See http://perl5.git.perl.org/perl.git/blob/09bef84370e90d727656ea11ba5ee8be80e361d3:/perly.y#l661 655 myattrterm: MY myterm myattrlist 656 { $$ = my_attrs($2,$3); } 657 | MY myterm 658 { $$ = localize($2,$1); } 659 ; 660 661 myterm : '(' expr ')' 662 { $$ = sawparens($2); } 663 | '(' ')' 664 { $$ = sawparens(newNULLLIST()); } The "myterm : '(' ')'" branch explicitly allows this syntax. It was added to perl in 1999. The fact that other passes of the compiler can't handle the generated structure is a bug (probably just an oversight, since the fix is literally four tokens long). > That my behaves "a little different" isn't new, we allow the special > use of undef in a my() declaration: > > my ($x,undef,$y)= @l; > > I contend that allowing my (); would make debugging difficult. I also > contend that it is meaningless/absurd to "declare zero items". To me your argument feels like you'd also want to make m/foo|/ invalid because it would be meaningless to "match zero characters". (And by extension 0 is not an actual number, because it would be meaningless to "count zero items".) In other words, I don't find it convincing. > Does C allow you to write: > > int; > > ? No, but it allows 'int ()'. It means something entirely different but that's because C is not Perl. (Does C allow you to write 'printf("%d", int i++)'?) LukasThread Previous | Thread Next