I would be interested to read you expound upon this aside.

My thinking was:

• As you say, who is ever going to test the results of die.
• But equally, where is the logic in testing the return of warn?

  If it fails, what are you going to do? warn about it.

  Maybe warn(...) or die(...); makes some sense; but then it would be better if warn itself died if it failed to warn. But what if die fails for teh same reason as warn. Should it warn> Or die? Or warn and die?

  Maybe it should send an SMS. But of course, that could fail also, and it would have to warn about that and then die :)

  That's mostly humour, but with the purpose of making a point.

For warn, a true return value enables structures such as warn "Loop failure\n" and next if $_ eq "bad"; that I feel (YMMV) are quite natural.

I also like the way warn ... and next reads, and have used it extensively. But, it is logically incorrect.

The next is not logically dependant upon the success of warn, and should not be made so.

In the unlikely event that warn failed, the next would not be actioned and the wrong action would result.

It should be -- and when I remember, I now code it as -- warn(...), next. Many people don't like the comma operator, but those same people probably wouldn't use warn and next either.

Now to why the though came up in my previous post. This:

for (1..5) {
    print if eval{
        do_foo() && do_bar()
    } or warn $@; 
}
[download]

Would be cleaner than:

for (1..5) {
    print if eval{
        do_foo() && do_bar()
    } or do{ 
        warn $@; 
        0 
    };
}
[download]

but currently would do the wrong thing.

Of course, it is too late now, but that doesn't detract from the notion that a failure return from warn is pretty useless.

Just as I finished my reply to your post, that same notion -- slightly differently formatted -- struck me too:

for (1..5) {
    eval{
        do_foo() && do_bar()
    } and print or warn $@;
}
[download]

And when I came to post that, I saw your update. T'is much cleaner.