The second paragraph summarizes nicely the whole thread, but I cannot agree with the best practice you are suggesting which is don't use it IIUC.

eval-require is a common idiom for conditional loading of modules and there is a need for that. From a language perspective a special "use" would be better like 'use any LIST' as the intent would be much clearer. Still you don't want "use base/use parent" wars^Wdiscussions for something simply expressed in an idiomatic but inelegant way. In the end I think low-level things like these should be made core pragmas and (possibly) written in C, thriving for a minimalistic implementation.

eval-require is a common idiom for conditional loading of modules and there is a need for that.

No, you don't need either eval functions to conditionally load a module.

if (condition) {
   require Foo::Bar;
}
[download]

And you don't need eval EXPR* to do exception handling.

eval {
   require Foo::Bar;
};
if ($@) {
   require Foo::Baz;
}
[download]

You only need eval EXPR to load a module whose name is not known at compile-time. The only things I can think of that fits that description are plugins/drivers, things well served by high-level modules.

Do you have an example that requires require $class other than plugins/drivers?

* — Remember, nothing wrong with eval BLOCK (called try in some other languages). Unlike eval EXPR, it doesn't invoke the Perl compiler. That means it doesn't incure a huge speed penalty and it doesn't require careful escaping and validation its argument.

My question was exactly about plugins/drivers, i.e. I'm working on a code base that does dynamic loading of plugins, and find my self having to write eval "require $class" because of that. I can't really think of many other cases either (perhaps a factory?).

still if you need a loop to pick up the first module to load of a list of modules (e.g say Math::Pari, GMP and other math libs). I am lazy and I don't want to write a require line for each one, or maybe I want to read my optional modules directly from the .yml shipped with the module etc...

cheers --stephan