At my age one learns to look before one leaps. It may be that it is an intentional design decision, not simply an oversight.

It's neither an intentional design decision, nor an oversight. In Perl, in general, arguments are evaluated before the sub (or op) is called. So, it's logical that the list is expanded first. It's only later that the case of foreach (x .. y) (but not foreach (x .. y, z) or foreach (z, x .. y)) got optimized as that was a common case, and a lot of memory (and hence, time) could be saved. My guess is that the author who implemented this optimization didn't think the case for grep or map was as pressing - one would expect the result (in list context) of the grep and map to be long lists as well.

Note that I wasn't trying to make a snide remark. People having itches is the main driving force behind Perl.

"no, no, we cant do that because of this".

If your patch doesn't break backwards compatability, and doesn't punish (slowdown, more memory usage, etc) code that doesn't benefit from your patch, there's a good chance it gets accepted. Even if it does contain bugs, isn't perfectly written or causes a problem on some platform you don't have access to, there's a good chance someone else cleans up your effort -- even if it takes a while. Contributions, even if not perfect, are welcomed.