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)

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

Doing it at run-time won't work. We're trying to issue the warning before the compilation error.

> Doing it at run-time won't work

And I'm talking about compile time:

Pragmas like use feature have the same import-timing like modules and all subs are declared at compile time.

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

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.

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

You mean less simplified? I posted the minimal case: feature enabled for use Try::Tiny;, but not enabled at the call site. If you want to created an obfuscated example, I'll leave obfuscation to you.

> You mean less simplified?

No I meant more plausible.

Perl is so flexible that you can most likely create false positives for every warning.

Doesn't mean they appear frequently enough for not being tolerable or solvable.

Here a similar example where redefine is causing a "false positive"

use strict;
use warnings;
use feature "say";
#no warnings 'redefine';
sub tst {1} 
BEGIN { $a = \&tst }
sub tst {2}
BEGIN { $b = \&tst }              
say &$a;
say &$b;
[download]

perl false_postive_redefine.pl
Subroutine tst redefined at false_postive_redefine.pl line 7.
1
2
[download]

And here a solution to your example.

Just move the use Try::Tiny into the scope where it belongs. This makes the code also far clearer.

use feature "try";
use constant CHECK_HINTHASH => 0;
sub check_hinthash {warn "feature_try = ".$^H{feature_try} if CHECK_HI
+NTHASH}
#...

BEGIN { check_hinthash() }    # feature enabled

{
  no feature qw( try );
  BEGIN { check_hinthash() }    # feature disabled
  use Try::Tiny qw( try catch );
   
  try { ... };   
}

BEGIN { check_hinthash() }    # feature enabled

# try { ... };  <-- would fail
[download]

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