Thanks for checking that. I somewhat suspected that it was a Perl bug that was likely fixed in a later edition which is why I included the version number in the bug description in the original post. I don't have a set up where it is easy to test a script against multiple versions so I especially appreciate your feedback.

I'm not sure I'd call it a "bug" which has been "fixed"; just a change. An enhancement. In older versions of perl, an eval block (including a module file) would evaluate to the value of its last evaluated expression. And return 1; is not an expression. Apparently, as of 5.10, an eval block can have a return statement as well.

What is the sound of Windows? Is it not the sound of a wall upon which people have smashed their heads... all the way through?

I wouldn't call it a change because eval blocks can have return statements in 5.8.8 as well which is where this "issue" (call it what you will) was found. I use returns in eval blocks all the time, in this idiom:

<c>eval { 
   ... something that can die ...
   #insures we never go into the do block except when we die
   return 1;
} or do { 
  my $e=$@;  #the exception
  ... exception handling here ...
};
[download]

That odd bit of code is needed because destructors can clear $@ so there are times when a routine dies but $@ is undefined or ''. On the otherhand, an eval block is guarenteed to return undef if it dies an unnatural death. Thus with the above idiom we can be sure that we will enter the do block if and only if the eval block dies before its time.

I would probably add the disappearing exception ($@ being cleared) to my list of odd and hard to track down bugs. It is easy to overlook it as a possiblity unless of course you are "in the know" that such things like disappearing exceptions can happen. Most tutorials on exceptions teach people to capture failure like this eval {...}; if ($@) {...} but if you use that idiom, the exception handling code will never be reached should something wipe out $@.

Apparently, as of 5.10, an eval block can have a return statement as well.

As ELISHEVA notes, this was possible before 5.10, too. From the 5.8.8 eval doc:

"In both forms, the value returned is the value of the last expression evaluated inside the mini-program; a return statement may be also used, just as with subroutines. The expression providing the return value is evaluated in void, scalar, or list context, depending on the context of the eval itself."