In hindsight it might be that Try::Tiny is complied before the -E takes effect.

Not sure about the compilation order here. °

In that case only something like an INIT {} block could catch the conflict.

°) redefining a built-in should fail...

> In hindsight it might be that Try::Tiny is complied before the -E takes effect.

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

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

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

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]