And I prefer to see the warning at the line where the use appears, not the one with conflicting 'try {}'.

In general any module exporting subs that conflict with potential built-ins should check at import time.

The needed code to check the hint-hash should be refactored from feature.pm into a separate module.

footnote

Like this no modules need to be patched.

Not sure if this is not an overkill tho.

If you can patch *feature.pm*, you can patch the *feature itself*. Both are Perl. No need to patch Try::Tiny to add a warning to Perl.

And I prefer to see the warning at the line where the use appears

Then we're back to false negatives and false positives. This subthread was discussing how to avoid those.

There are no false negatives if you patch both modules, and your example of false positives is not plausible.

There is still a conflict, no falsehood there. You just amended the code later to avoid a real error in a sub-scope. The outer scope is still vulnerable for misinterpretation. And if the outer scope was never meant to use Try::Tiny::try() why even import it there?

I gave a similar example of redefining a sub, which is written in a way that no real error happens. And it will nonetheless emit a warning.

Now by your definition it's a false positive.

By my logic the warning is in both cases economically justified, because it will only happen in very unusual or willfully constructed cases, make the author think about his dangerous design and can be trivially "solved" by disabling the warning.

There are tons of examples of applications of no warnings 'redefine' in the monastery and I doubt anyone ever seriously called those cases "false positives".

Anyway we are at Re:21 now, I think my point is clear by now ... :-)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}