Since you mention it, could you also summarize why? Seems a bad idea to me. I mean, we have a case right here where it would have caught a mistake. What is the point of allowing people to write useless constructs, especially when it is easy to write them by accident?

I agree with you. I don't know why this was done. Sounds like a case of consistency gone wrong, but maybe it's a side effect of another fix?

---

Executing the following should find the commit in which this changed.

git clone git://perl5.git.perl.org/perl.git perl
cd perl
./Porting/bisect.pl --target=miniperl --start=v5.16.0 --end=v5.18.0 \
    --expect-fail -e 'grep(1)'
[download]

Until Monday, the only unix machine to which I have access is my web server, and my web host frowns on spending that much CPU. :)

Had some spare cycles, so gave it a go... didn't take long to come back with the commit quoted below. It's over two years ago now (first appeared in v5.17.2), and from the commit message looks like maybe a path where the check doesn't happen was overlooked?:

commit c087f08cbf44e0e4794563768e3adf95e484be98
Author: Father Chrysostomos <sprout@cpan.org>
Date:   Sat Jul 14 12:28:15 2012

    op.c: ck_grep does not need to check num of args

    It calls ck_fun first, which does the same check, so it is
    unnecessary.

diff --git a/op.c b/op.c
index acea933..b5a78d5 100644
--- a/op.c
+++ b/op.c
@@ -8622,8 +8622,6 @@ Perl_ck_grep(pTHX_ OP *o)
     }

     kid = cLISTOPo->op_first->op_sibling;
-    if (!kid || !kid->op_sibling)
-       return too_few_arguments_pv(o,OP_DESC(o), 0);
     for (kid = kid->op_sibling; kid; kid = kid->op_sibling)
        op_lvalue(kid, OP_GREPSTART);