To me the most interesting thing you say here is this: But, in fact, they're all fairly idiomatic and common Perl.

That is the key difference. Common idioms that are widely recommended in books, on mailing lists, and sites like this one, are fair game in my opinion. If someone doesn't know how to slurp a file, he should learn. On the other hand, goto is not common or recommended (though not deprecated in this form). The comment from tilly that inspired this thread basically said that he could imagine a situation where he might want to use goto, but it had never happened and he didn't think it ever would.

Remember, the only advantage that goto has in this situation is that it replaces the current sub in the call stack so that you can't tell it wasn't called directly in the first place. I consider this a disadvantage in most circumstances since it will make things more confusing to debug.

Um, that wasn't what I basically said.

The quote you are paraphrasing from goes:

I have not personally ever felt the desire to (other than in deliberate experimentation) use a goto in Perl for anything other than subverting the stack. However I remain aware that I could, and I would do it without hesitation if I thought the situation warranted it. I also doubt I will ever encounter such a situation, but I think I could likely spot it if I did...

Which means that I have used goto. In production code. For exactly what Ovid is doing, namely subverting the stack. While I wouldn't use a goto for that here, it is sometimes the right thing to do. An example is in an import method. Take a look at, for instance, Versioned modules. Why do I need to do it there? Quite simply because I need to remove myself from the call-stack so that an import method which knows nothing of me will export anything it exports to the correct package.

Actually, I have used goto in production when there was a perfectly good construct, namely the continue block.

(What, you had to click and find out what it did? Hrmmm... maybe goto is more maintainable from a knowledge standpoint.)

I had a large while loop that iterated over an array that was constructed earlier. I did some stuff, then had a set of if-then statements. Yes, I could've built this out to be a series of functions, but, as this was the meat of the script, didn't feel that was warranted. I did want to be able to "return" out of the first if-block and continue processing after the last else. So, I put a label up, called it DONE, and used goto quite liberally.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Okay, thanks for the correction and example.

It seems to me that the grep example shouldn't be used anyway, because you're modifying $_ en passent. This can lead to all kinds of problems, not the least of which is a lower level programmer misunderstanding why this is bad.

Doing that in two lines seems to be a bit better, if more verbose:

s/foo/bar foreach @arr;
return grep { /bar/ } @arr;
[download]

update: excuse my slow thinking

i first thought that clintp was demonstrating canonical use of grep, which is documented, but difficult to understand at first (akin to canonical use of map). i feel sheepish. It now behooves me to think that he was in fact directing his snippet at what i was trying to point out: a subtle feature that is documented and so able to be understood (and used in production code).

i feel there is still a point to be made however. While most of his other code snippets could be discovered plainly from documentation, this example is a bit more insidious. The student learning grep will probably not "get" what is being said in the documentation about this feature (i know i didn't the first few times through it). More to the point, while clintp's example is fine, a learning student would probably not notice the pitfall, since it doesn't directly follow; thinking they will is, sadly, overestimating their intelligence. Then later they could easily try altering $_ and get bizarre results.

In the end, it seems better to avoid this usage in code for maintainability, whereas the other examples seem perfectly valid. Maybe it's just me...