> It doesn't matter when the Try::Tiny is compiled.

I've explicitly tested this with feature::feature_enabled() and order definitely matters.

It's basically the difference between:

use feature "try";
use Try::Tiny;
[download]

vs

use Try::Tiny;          # no chance (well see footnote°)
use feature "try";
[download]

And that's because lexical scope starts right at the point of declaration.

> it's out of reach of Try::Tiny since I believe it's intentionally a pure-Perl module.

It's very much possible with a pure-Perl module like I said. The _enabled routines in feature are basically checking the hinthash %^H returned by caller for the needed level.

And the hint-key is called "feature_try"

A slight complication is that feature introduced "try" before it provided the *_enabled checks. IOW one needs to copy the hint-hash lookup logic for older Perl versions.

Footnotes

°) the wrong order could be fixed by using an INIT {} block doing the check after all compilations are completed, but I question the wisdom of such a fragile construct. Too many edge cases.¹

¹) Turns out that neither INIT,CHECK or UNITCHECK can see the hint anymore.

update

little demo v5.38

 perl -E'BEGIN{say join "\n",feature::features_enabled()}'
bareword_filehandles
bitwise
current_sub
evalbytes
fc
indirect
isa
module_true
multidimensional
postderef_qq
say
signatures
state
unicode_eval
unicode_strings
[download]

It's very much possible with a pure-Perl module like I said. The _enabled routines in feature are basically checking the hinthash %^H returned by caller for the needed level.

But the problem is that the code isn't even compiled into a call to Try::Tiny's try, so how is it supposed to check the hints? That requires hooking into the compiler.

Not sure what you are objecting about, the newest feature has code examples showing how an import() of a module can check the hinthash of the caller.

Try::Tiny or others could do this too, if they come second.

From feature_enabled($feature, $depth)

package MyStandardEnforcer;
use feature ();
use Carp "croak";
sub import {
  croak "disable indirect!" if feature::feature_enabled("indirect");
}
[download]

And yes, the implementation of feature_enabled() is in pure Perl.

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

Any reason you didn't provide your tests? Because my testing confirms what I said.

$ perl -e'
   use feature qw( try );
   use Try::Tiny;
   try { };
   CORE::say "ok";
'
syntax error at -e line 4, near "};"
Execution of -e aborted due to compilation errors.
[download]

vs

$ perl -e'
   use Try::Tiny;
   use feature qw( try );
   try { };
   CORE::say "ok";
'
syntax error at -e line 4, near "};"
Execution of -e aborted due to compilation errors.
[download]

And

$ perl -e'
   use feature qw( try );
   use Try::Tiny;
   { no feature qw( try ); try { }; }
   CORE::say "ok";
'
ok
[download]

vs

$ perl -e'
   use Try::Tiny;
   use feature qw( try );
   { no feature qw( try ); try { }; }
   CORE::say "ok";
'
ok
[download]

So I repeat: The order in which they are loaded is irrelevant, and what matters is if the feature is enabled or not when the try is encountered.

I never doubted that feature "try" will dominate, regardless of the compilation order.

I said that the order matters in attempting to warn about the conflict during import/activation.

-->

> I think Try::Tiny should attempt to warn you or die.

In the OP's example Try::Tiny is activated first and can't know about a later feature.

This case must be addressed by the features.

Or more generally, only the second "change" can detect the first.

FWIW: I started a discussion on Reddit while PM was unreachable:

Perl's feature.pm and backwards incompatibility

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