Re^2: Make $^V and "my" implicit

In what circumstances could...

use $^V;
[download]

...possibly be useful?! You really want a script that imports 5.16 features when it's run under Perl 5.16, and 5.14 features when it's run under Perl 5.14?

The new features in Perl 5.16 are 'unicode_eval', 'evalbytes', 'current_sub', and 'fc'. Does your script use those features?

Yes: then use v5.14 is not sufficient, so use $^V is not sufficient when run under Perl 5.14. So you should explicitly write use v5.16.
No: then use v5.16 would be overkill, so use $^V is overkill when run under Perl 5.16. So you should explicitly write use v5.14.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

Comment on Re^2: Make $^V and "my" implicit Select or Download Code

Replies are listed 'Best First'.
Re^3: Make $^V and "my" implicit by Anonymous Monk on Feb 04, 2014 at 13:48 UTC
I didn't mean it literally so should have written it as `use <version string>` I disagree, though. If whatever new version of Perl is installed on my machine I should not have to manually enable its new features.	[reply] [d/l]
Re^4: Make $^V and "my" implicit by tobyink (Canon) on Feb 04, 2014 at 15:27 UTC
Generally speaking, you don't need to manually enable new features. Recent features like the defined-or operator (`//` and `//=`), and `s///r`, and the `package NAME BLOCK` syntax, and so on, work out of the box in new versions of Perl. You don't need to explicitly enable them. The exception to this rule is for things like `state`, `say`, `fc`, and so on, which before becoming new Perl features, were already syntactically correct Perl. Thus people could have been using functions with these names already. Enabling them implicitly would break existing Perl scripts, thus they need to be enabled explicitly. `use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name`	[reply] [d/l] [select]