I started doing this with my scripts back in 5.12. The practice has aged well. When editing a script that I haven’t touched in a while, the version number gives me helpful context. I can often tidy up my code by bumping the version number before editing, then massaging towards modern best practices during testing/debugging. I’m glad to see Perl doubling-down on use v....
Regarding the strategy of making “use v7” opt in in Perl 7. I would consider flipping it around … make “use v5” the thing you opt in to.
I think “use 5.36” makes sense for minor versions. You want to preserve compatibility by default in almost all releases. But for the major versions, you should be proud of your new features :)
Making people do the slight amount of effort to add “use v5” would also give them a chance to understand the alternative of porting their code to Perl 7, and unlocking many features.
Because modules? Having the interpreter name set the compatibility level globally is the same kind of problem as -w instead of use warnings. use v7 (or use <version> in general) says “this code is onboard with new standards” without breaking everything you use.
Or you could use a perl5 binary, or a use v5 pragma in a perl7.
The very conservative approach to upgrades is fascinating, but if you adopt a new major version of a language, why wouldn’t you expect to get its features for free? What’s the point of calling it 7, if you don’t do that?
I don’t think there’s much use in a new major version at all, except that some day the version that comes after 5.98 is going to be a bit inconvenient (aka the Linus Can’t Count to 40 argument).
It would also be possible to control this default with a command line flag and/or env var. Either would allow a script wrapper to function as a perl5 drop-in replacement.
I started doing this with my scripts back in 5.12. The practice has aged well. When editing a script that I haven’t touched in a while, the version number gives me helpful context. I can often tidy up my code by bumping the version number before editing, then massaging towards modern best practices during testing/debugging. I’m glad to see Perl doubling-down on
use v....Perl 5 forever! :-) The way things are going this might actually be the case.
This is fine by me.
Regarding the strategy of making “use v7” opt in in Perl 7. I would consider flipping it around … make “use v5” the thing you opt in to.
I think “use 5.36” makes sense for minor versions. You want to preserve compatibility by default in almost all releases. But for the major versions, you should be proud of your new features :)
Making people do the slight amount of effort to add “use v5” would also give them a chance to understand the alternative of porting their code to Perl 7, and unlocking many features.
Isn’t that kind of the opposite of staying compatible with old scripts? After all they’d need to add this.
This! I was with everything until
use v7. Why isuse v7not the default when I invokeperl7.0? Seemed silly.Because modules? Having the interpreter name set the compatibility level globally is the same kind of problem as
-winstead ofuse warnings.use v7(oruse <version>in general) says “this code is onboard with new standards” without breaking everything youuse.Or you could use a perl5 binary, or a
use v5pragma in a perl7.The very conservative approach to upgrades is fascinating, but if you adopt a new major version of a language, why wouldn’t you expect to get its features for free? What’s the point of calling it 7, if you don’t do that?
I don’t think there’s much use in a new major version at all, except that some day the version that comes after 5.98 is going to be a bit inconvenient (aka the Linus Can’t Count to 40 argument).
It would also be possible to control this default with a command line flag and/or env var. Either would allow a script wrapper to function as a perl5 drop-in replacement.