Re^5: Try::Tiny and -E

you are wrong on both accounts.

> 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]

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.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

see Wikisyntax for the Monastery}

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]

Comment on Re^5: Try::Tiny and -E Select or Download Code

Replies are listed 'Best First'.
Re^6: Try::Tiny and -E by ikegami (Patriarch) on Dec 29, 2025 at 07:28 UTC
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.	[reply] [d/l]
Re^7: Try::Tiny and -E by LanX (Saint) on Dec 29, 2025 at 12:05 UTC
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}	[reply] [d/l] [select]
Re^8: Try::Tiny and -E by ikegami (Patriarch) on Dec 30, 2025 at 00:04 UTC
That solution will give both false positives (warn when it shouldn't) and false negatives (not warn when it should). The order loaded will determine if you can get false positives or false negatives, but it you can get false results regardless of the order in which they are loaded. Again, the order in which you load the modules is irrelevant. And that's because you're checking at the wrong time to get consistent results. For that, you need to check when `try` use is compiled, not when the module is loaded.	[reply] [d/l]
Re^9: Try::Tiny and -E by LanX (Saint) on Dec 30, 2025 at 03:17 UTC
Re^10: Try::Tiny and -E by ikegami (Patriarch) on Dec 30, 2025 at 05:01 UTC
Some notes below your chosen depth have not been shown here
Re^6: Try::Tiny and -E by ikegami (Patriarch) on Dec 29, 2025 at 07:01 UTC
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.	[reply] [d/l] [select]
Re^7: Try::Tiny and -E by LanX (Saint) on Dec 29, 2025 at 11:56 UTC
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}	[reply] [d/l]
Re^8: Try::Tiny and -E by ikegami (Patriarch) on Dec 30, 2025 at 00:02 UTC
In the OP's example Try::Tiny is activated first and can't know about a later feature. I think it can check correctly, but I'm not sure. If it can, it can do so regardless of whether it was loaded first or not. And if it can, it's not trivial. More importantly, is it even its job? After all, the following doesn't warn: `sub print { ... } print ...;` [download] Maybe this is something Perl::Critic can handle.	[reply] [d/l]
Re^9: Try::Tiny and -E by LanX (Saint) on Dec 30, 2025 at 03:10 UTC
Re^10: Try::Tiny and -E by ikegami (Patriarch) on Dec 30, 2025 at 05:06 UTC