see feature*_enabled checks demonstrated in Re^5: Try::Tiny and -E and Re^7: Try::Tiny and -E

Try::Tiny can check either inside import() or die/skip right at the beginning of the module.

NB: you can provide a caller level to this routines.

> If you perform the check as these wrong times,

What should be the benefit of Try::Tiny exporting it's subs while feature-try is enabled?

In theory you could no feature "try" later in a sub-scope to re-enable those exports, but that's a very convoluted edge-case.

And I was mostly talking about "warning", warnings can be disabled if this convoluted edge-case is warranted.

Looking forward to your counter-examples!

Try::Tiny can check either inside import() or die/skip right at the beginning of the module.

False positive:

use v5.40;

use Try::Tiny qw( try catch );

...

{
   # Code that hasn't been converted to 5.40 yet, for example.
   no feature qw( try );

   try { ... };   
}

...
[download]

False negative:

use Try::Tiny qw( try catch );

...

{
   use feature qw( try );

   try { ... } catch ( $e ) { ... }
}

...
[download]

What should be the benefit of Try::Tiny exporting it's subs while feature-try is enabled?

I didn't say it shouldn't be done. I said it doesn't always work. To evaluate if it should be done or not, it's important to know when it won't work correctly.

> False negative:

As I already said:

In this case feature "try" would need to warn about the subs in the caller's stash.

But that's also a convoluted edge case.

If one really needed to activate both Try::Tiny and feature try inside the same file - let's say while gradually refactoring legacy code - and wouldn't want to see the warning, it would be acceptable to require from the author to deactivate the warning class ( no warnings "shadow" or "mask" or whatever)

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

> False positive:

as I already said

> > In theory you could no feature "try" later in a sub-scope to re-enable those exports, but that's a very convoluted edge-case.

> > And I was mostly talking about "warning", warnings can be disabled if this convoluted edge-case is warranted.

Nobody does this accidentally or he/she is just dumb copy-pasting. Requiring to silence the warning with something like no warnings "masking" would be adequate. (there is no warnings category "masking" yet, but shadow exists, That's a matter of debate)

Anyway, do you have an example of a false positive which is less constructed?

FWIW: I provided an example for a false positive on reddit, if feature-try (Not Try::Tiny) is activated inside a class and was warning about name-clashes with method-names. This wouldn't make sense, because methods can't clash with built-ins.

But this is also kind of convoluted, methods are not imported and features are activated in the head lines of a scope/file, before methods are defined.

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