Indeed. In this special case it's actually too early to check from within Try::Tiny.

I checked with feature::feature_enabled("try"); and feature::features_enabled($LEVEL); for various levels.

But the case of perl -E'use Try::Tiny; try {1/0}' could be checked, and from what I see is Try::Tiny not attempting to catch this.

So haarg's reply to the ticket is not fully correct.

On another note: I'm wondering, shouldn't Perl warn if a built-in is clashing with an (exported) sub???

EDIT

Ticket updated.

Given the difficulties for a module to test whether one of its routines could clash with a built-in, the solution is easy:
1. State clearly in the docs that as from Perl 5.40 there may be a clash with a built-in;
2. Have Try::Tiny check it is running under Perl 5.40 or later and issue a warning about a possible clash.
And leave it to the programmer to do what is necessary. No need to add unnecessary complexity and fragility to a Tiny::* module.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

Does it really make sense to make all Try::Tiny-using application start issuing warnings just by upgrading to Perl 5.40?

I agree that this shouldn't be for Try::Tiny to address (except in documentation).

> Have Try::Tiny check it is running under Perl 5.40 or later and issue a warning about a possible clash.

This:

• $^V gt v5.40.0

doesn't make much sense since feature "try" is already available for earlier versions. Furthermore does Perl 5.40 not activate it by default, you still need use v5.40 inside.

Checking the hinthash of the importing scope for a key feature_try is far more reliable and generates far less false positives.

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

It doesn't matter when the Try::Tiny is compiled. Features have a lexical scope, so it's all about the context in which the try keyword is compiled. And while that is possible to check that context to see if the feature is enabled, it's out of reach of Try::Tiny since I believe it's intentionally a pure-Perl module.

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]

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.

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]

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.

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.