DEV Community: Dan

The Perl Shebang

Dan — Sun, 04 Jul 2021 22:36:55 +0000

Often overlooked, the shebang of a Perl program is a comment on the first line which tells the (Unix-like) OS how to run the script when invoked directly on the commandline. (It's ignored on Windows, which only looks at the file extension.)

#!/usr/bin/perl
use v5.16.0;
use warnings;
say "Hello world";

chmod a+x myscript.pl
./myscript.pl

But there isn't one right answer for what the shebang should be. /usr/bin/perl may be commonly available, but not always, and may not be the perl the user prefers.

For Perl scripts that are distributed to users to run how they wish, use env to run the perl that comes first in PATH:

#!/usr/bin/env perl

Perl scripts distributed on CPAN, however, get installed to a specific perl with their dependencies, so their shebang must also point to that perl. This is handled by a shebang rewrite step in the installation process, but it doesn't work for an env shebang for historical reasons.

For Perl scripts distributed via CPAN installation, you can use any single-word shebang that ends in perl, even just perl:

#!perl

While developing and testing, the shebang will not have been rewritten yet, so you can invoke it as perl script/myscript.pl to run it with your preferred perl and ignore the shebang. If the script depends on modules in lib/ in the same distribution, it is common to run it during development as perl -Ilib script/myscript.pl.

Finally, when you deploy and install a script manually, it should be run with a specific perl so that it doesn't suddenly start running with a different perl from the one it was deployed for, which may not have the script's dependencies installed or may behave subtly differently.

For Perl scripts deployed to a specific location, use the full path to the perl that should run it on that machine:

#!/usr/bin/perl
#!/opt/perl/bin/perl
#!/home/user/perl5/perlbrew/perls/perl-5.34.0/bin/perl
#!/home/user/.plenv/versions/5.34.0/bin/perl

You may also find Perl scripts with flags specified in the shebang with hyphens. This doesn't work with env shebangs in many cases, but the two common flags used this way are -w for warnings and -T for taint mode. -w is unnecessary and discouraged; just use warnings; instead.

CGI::Tiny - Perl CGI, but modern

Dan — Sun, 30 May 2021 21:44:36 +0000

In a previous blog post, I explored the modern way to write CGI scripts using frameworks like Mojolicious. But as pointed out in comments, despite the many benefits, there is one critical problem: when you actually need to deploy to a regular CGI server, where the scripts will be loaded each time and not persisted, frameworks designed for persistent applications add lots of overhead to each request.

CGI scripts have historically been written using the CGI module (or even more ancient libraries). But this module is bulky, crufty, and has serious design issues that led to it being removed from Perl core.

Enter CGI::Tiny. It is built for one thing only: serving the CGI protocol. In most cases, frameworks are still the right answer, but in the case of scripts that are forced to run under the actual CGI protocol (such as shared web hosting), or when you want to just drop in CGI scripts with no need to scale, CGI::Tiny provides a modern alternative to CGI.pm. You can explore the interface differences from CGI.pm or suggested ways to extend CGI::Tiny scripts.

So without further ado, here is the equivalent CGI::Tiny script to my previous blog post's examples:

#!/usr/bin/env perl
use strict;
use warnings;
use CGI::Tiny;

cgi {
  my $cgi = $_;
  my $input = $cgi->param('input');
  $cgi->render(json => {output => uc $input});
};

Dist::Zilla @Starter Revision 3 - Git, versioning, and more

Dan — Thu, 11 Mar 2021 23:46:33 +0000

I've just released revision 3 of the @Starter plugin bundle for the Dist::Zilla CPAN distribution authoring tool. There's no changes to the base configuration from revision 2, but there are now additional options to help manage common authoring tasks using modern best practices. You must set your revision to 3 to enable these new options, as a safety measure to make sure you have a new enough version of the bundle to support them.

The managed_versions option is the most complex new addition. Instead of declaring a distribution version in your dist.ini or using a plugin like [Git::NextVersion] or [AutoVersion] to determine it, this option lets you version your modules like you normally would and reads the version of your main module to use as the distribution version. The versions of any other modules in the distribution are updated to match in the build or release, and after a release it's incremented in the source files. This is widely considered the least fragile and most contributor-friendly method of managing versions with Dist::Zilla currently, as your modules don't require Dist::Zilla to determine their version while testing.

The regenerate option makes use of a very useful quasi-phase called -Regenerator created by Kent Fredric. For each filename you specify, it copies this file from the Dist::Zilla build tree to your source tree whenever you release as well as when you run dzil regenerate. This can be useful for keeping generated files such as LICENSE in your git repository where they may also be important, as well as copying your Makefile.PL/Build.PL and META.json to your source tree if you wish to make it directly installable with cpanm for testing or Travis CI. (Note: this method is only for testing unreleased changes, you should always install distributions from CPAN normally.)

Finally, revision 3 made it possible to release the @Starter::Git variant bundle, which takes all of the same options as @Starter, and interleaves plugins appropriate to a Git workflow. [Git::GatherDir] replaces [GatherDir], as it's a simple subclass that prevents cruft from being gathered by simply gathering the files tracked in Git. This means your .gitignore can be used to exclude files from both the repository and your distribution builds. This mostly obsoletes the need for [PruneCruft] and [ManifestSkip] to clean up your distribution build, but the bundle still includes them as they don't tend to cause any problems. In addition, the bundle will check for any uncommitted changes before releasing, and after releasing commit and tag the release (as well as a separate version bump commit if you also enable managed versions), and push to your Git origin if you have one configured.

The @Starter::Git bundle also comes with a matching Dist::Zilla minting profile, which is similar to the @Starter profile but additionally adds a basic .gitignore to start you out, and initializes the new directory as a Git repository.

I hope these new options are helpful in modernizing your distribution workflow. As always, any plugins used by the bundle can be fully configured by config slicing, you can even look at the new bundle's dist.ini for examples of using itself. Please stop by #distzilla on irc.perl.org if you have any questions, big or small, we are happy to help.

Since the original publication of this post, @Starter and @Starter::Git have reached revision 5, with a few minor enhancements.

Dist::Zilla @Starter - Revision 2

Dan — Wed, 10 Mar 2021 20:41:13 +0000

I recently released revision 2 of the @Starter plugin bundle for Dist::Zilla. This revision brings small improvements to the default behavior, as well as the option to set a different installer plugin. In order to use the new revision, you must set the option "revision = 2" when using the bundle.

Revision 2 uses [Pod2Readme] instead of [ReadmeAnyFromPod] to generate the text README file. [ReadmeAnyFromPod] is a great and flexible plugin, but [Pod2Readme] is much simpler for the specific purpose of generating a text README. For any additional README files in other formats, I still recommend using [ReadmeAnyFromPod].

This revision also sets the option "inherit_version" in [MetaProvides::Package] to 0 by default. This makes no difference if your distribution contains uniform module versions, or for modules which have no version (they are still marked as having the distribution version unless you set "inherit_missing" to 0 as well), but if you have modules with different versions hardcoded, this will reflect that in the "provides" metadata.

The new "installer" option allows you to swap out the default [MakeMaker] installer plugin. The primary reason to do this is to use [MakeMaker::Awesome] when you need to customize portions of the generated "Makefile.PL". There is also the option to use [ModuleBuildTiny] or [ModuleBuildTiny::Fallback] if your distribution is simple enough to use Module::Build::Tiny as your installer.

I recommend upgrading to Revision 2 if you are currently using @Starter or @Basic. Check out the documentation for details, and come visit #distzilla on irc.perl.org if you have any questions or issues.

Since the original publication of this post, @Starter has reached revision 5 and the @Starter::Git variant bundle has been added for additional convenience. I will be republishing my other posts on @Starter in the coming week.

Dist::Zilla - Why you should use @Starter instead of @Basic

Dan — Tue, 09 Mar 2021 19:07:20 +0000

I posted previously about a new "starter" bundle for Dist::Zilla, the CPAN author's automation tool. I'd like to briefly try to answer the question: "Why should I care?"

If you're already happily using Dist::Zilla with an extensive configuration or plugin bundle of your own, this bundle isn't for you. But maybe you can get some ideas from the included plugins, I added a few to my author bundle!

If you're looking to get started in Dist::Zilla, the @Starter bundle makes a great starting point. Usage is similar to @Basic and all of the same information in the dzil.org tutorial applies.

If you're currently using @Basic, there are a few reasons you should consider switching over. @Basic has become somewhat outdated as it needs to maintain compatibility with existing configs; @Starter modernizes the base plugin set. For example, it includes the important [MetaJSON] plugin for generating modern CPAN metadata, and it uses [RunExtraTests] to run xt/ (extra) tests directly, which is now generally preferred over rewriting them into the t/ directory with the [ExtraTests] plugin. It also adds a few popular plugins, such as [Test::ReportPrereqs], which generates a test that lists all distribution prereqs and the currently installed versions, very helpful for debugging test failures.

Even if you're already including all of these improvements yourself on top of @Basic, using @Starter can cut down on the boilerplate in your dist.ini, and you can simply remove any plugins you want to leave out, or configure included plugins directly via config slicing. Plus, it can help incorporate new practices and features; @Starter will include future updates as new revisions, which you can review and switch to by setting the revision number in your dist.ini. This allows it to stay modern without breaking existing configs.

Switching from @Basic to @Starter is generally straightforward. Most minimal configurations can be directly switched over, removing any manually-included plugins that @Starter adds itself. If you are using @Filter, you can instead apply the -remove option directly to @Starter. The "CONFIGURING" section of the documentation goes over the most common ways to configure the bundle.

Feel free to stop by #distzilla on irc.perl.org or send me an email (address listed in module documentation) if you have any questions about the bundle, configuration, or Dist::Zilla in general. Happy releasing!

Dist::Zilla::PluginBundle::Starter - A new way to start using Dist::Zilla

Dan — Mon, 08 Mar 2021 20:04:20 +0000

Dist::Zilla is an extremely powerful and versatile CPAN authoring tool, which has enabled me to reliably publish many distributions with minimal fuss. It has the ability to automate your entire distribution building, testing, and releasing process, customized to almost any workflow, but this ability does not come without cost. One of the biggest difficulties newcomers face is sorting out the overwhelming number of available plugins and how to use them together effectively. A good way to start is with the tutorials at dzil.org and the standard @Basic plugin bundle. Unfortunately, the @Basic bundle is out of date; notably, it does not include the [MetaJSON] plugin, to generate META.json which is now the preferred metadata format for CPAN distributions. For backwards compatibility reasons the bundle itself can't easily be updated with new plugins.

@Starter is an attempt at an improved, more customizable beginner's plugin bundle, with a revision feature to try to avoid the problem of stagnation while being able to retain backwards compatibility. The revision defaults to 1 unless set explicitly, and future incompatible changes will be made by adding new revisions, which must then be selected by the author using the bundle. Also, the popular PluginRemover and Config::Slicer plugin bundle roles are composed in, allowing the author to remove or configure bundled plugins as desired.

The first revision also includes a number of improvements and updates to @Basic, while remaining unopinionated and unobtrusive. The previously mentioned [MetaJSON] is included by default, as well as a few plugins for more complete distribution metadata, and a few plugins that add basic sanity tests to the build. Two of the tests are author-only tests that check that the pod syntax is valid and the modules compile. The third is a simple test that prints a report of the installed prerequisites, useful for diagnosing test failures. [RunExtraTests] is included instead of [ExtraTests], because instead of moving and rewriting your extra tests (tests in xt/), it leaves them there and modifies Dist::Zilla's testing routines to run them directly. Finally, [ReadmeAnyFromPod] is used instead of [Readme] to generate a text README from your main module's documentation, rather than a generic README.

These plugins are sufficient to build and release a complete distribution reliably, but there are many more tasks Dist::Zilla can automate for you, like maintaining your module versions and automatically managing git or other version control. The "EXTENDING" section of the documentation describes some of the available options. Many of these are features of miyagawa's excellent Dist::Milla bundle, which is much more opinionated, but can be another great way to start using Dist::Zilla if you use git version control, and heavily influenced my own author bundle.

I hope this new bundle is useful to those getting started with Dist::Zilla or just looking for an updated bundle similar to @Basic, and as with all matters Dist::Zilla, please stop by #distzilla on irc.perl.org if you need help!

Encode::Simple - Encode and decode text, simply

Dan — Thu, 04 Mar 2021 19:16:44 +0000

Encode is a well known core module in Perl with support for encoding and decoding text from almost any character encoding you can think of. But it's also an old module with a large amount of historical cruft.

With inspiration from #perl on freenode IRC, Encode::Simple is an attempt to at least improve on its interface and usability issues. Rather than an awkward and unintuitive bitmask and the option of clobbering the input data, Encode::Simple exports straightforward encode and decode functions that simply return the encoded or decoded result or throw an exception. For the cases where you want to allow invalid characters or byte sequences, encode_lax and decode_lax are provided.

Encode itself supports many more operations such as partial, mixed, and in-place encoding or decoding, where its options may make more sense, but these uncommon use cases are not supported by Encode::Simple.

As a final note, if you are working strictly with UTF-8, I suggest avoiding Encode entirely and using the excellent Unicode::UTF8, or the related filehandle layer :utf8_strict, for fast and correct encoding and decoding.

Since the original publication of this post, Encode::Simple has added encode_utf8 and decode_utf8 functions that directly use Unicode::UTF8 if installed.

A Guide to Versions in Perl

Dan — Wed, 03 Mar 2021 00:52:22 +0000

Version numbers in Perl are very important; they allow orderly updating and maintenance of modules and distributions across the CPAN, and allow CPAN modules and consumers to require the versions of modules with the bugfixes or features they need. However, in this context, they are also a very unique beast with a complex and bumpy history that leads to some surprises for those who are not familiar with the nuances. These are the things CPAN authors should know about versions in Perl, and are nice for consumers to know as well.

To summarize:

Versions in Perl come in two forms, decimal numbers and dotted decimal tuples.
The two formats can be compared using a defined conversion method, implemented by the version module.
Versions for modules should be declared as string values.
Underscores can be used in either form of version to indicate a trial version, but have pitfalls to watch for.
The VERSION method can be used on any module to test if it's a certain version or greater, and version objects can be used for arbitrary version comparisons.

Version Schemes

To start with, it's important to know that there are two distinct types of versions recognized by Perl. The first kind is simply a decimal number, with digits before and after a decimal separator, for example '1.0' or '0.003'. These versions are compared as numbers, so '1.1' and '1.10' refer to the same version. Despite being numbers, they should always be declared and referenced as strings within the code, so that any trailing zeroes are kept around for consistency in display, and to avoid possible floating point errors for versions with a particularly large number of digits.

While decimal number versions are a simple concept, they are different from the versions used by most everything outside of Perl. For that, Perl recognizes a second type of version: a tuple (or sequence) of integers separated by dots, sometimes referred to as "dotted-decimal" versions, and used for the concept of semantic versioning. These look like 'v1.2.3' and 'v0.0.30'. For these versions, each segment is an integer, so trailing zeroes are significant -- 'v1.2.3' is the same version as 'v1.02.03', but not the same as 'v1.20.30'. Each segment after the first must also be 999 or lower, to allow conversion as described in the next section.

Neither of these version forms allow alphabetic characters or hyphens, as you may see in other versioning schemes. I'll go into the use of underscores later.

Responsible for parsing and disambiguating these two types of versions, as well as performing version comparisons as described below, is the module version.pm (referred to in this way to disambiguate from the word "version" itself). It has been a core module since Perl v5.10.0, and it is also dual-life, so you can install a newer version from CPAN on any version of Perl (which is helpful for reasons that will become apparent). It disambiguates these two types with simple rules: if the version contains a leading "v" or more than one decimal separator, it's a version tuple; otherwise, it's a decimal number. For this reason it's best to include both a leading "v" and at least two decimal separators for clarity when using tuple versions.

Comparing and Converting

For the sake of comparison, a conversion method is defined between the two types of versions. The first integer in a tuple version and the integer component of a decimal version are considered the same, and each successive segment of the tuple version is considered equivalent to three decimal places in a decimal version. So for example, to convert the version '3.01002' to a tuple version, the first segment is 3, the second is 10, and the third is 20 (padding with zeroes so you have groups of 3 decimal places), resulting in 'v3.10.20'. To convert the version 'v0.4.1' to a decimal version, the integer component is 0, the first three decimal places after the separator are 004, and the next three are 001, resulting in '0.004001'.

AAA.BBBCCC <-> vAAA.BBB.CCC

This method extends to however many segments or decimal places a version may have. The conversion is used by version.pm to compare version objects sourced from either scheme of version. In this way, Perl can determine how one version compares to another even when they are using different schemes.

Declaring Versions

Version numbers of each of these forms are not only recognized by Perl for the purpose of checking module versions at runtime, but also by the PAUSE indexer when indexing CPAN modules. In this case and similarly when versions are extracted using Module::Metadata, the behavior is to find the declaration of $VERSION and execute only that line in isolation, so your version declaration line must be executable on its own. The simplest and standard form of declaration is:

our $VERSION = '1.02'; # for decimal versions, or
our $VERSION = 'v1.2.3'; # for tuple versions

As noted in David Golden's blog post Version Numbers Should Be Boring, support for tuple versions has varied widely among old versions of Perl. As support is mostly based on the version.pm module, which is core after Perl v5.10.0, you need to take special care if your module will use tuple versions on Perl v5.8.9 or older. Your module should declare a dependency on version.pm (at least version 0.77, but preferably more recent), and declare the version in this way:

use version 0.77; our $VERSION = version->declare('v1.2.3');

Keeping this whole declaration on a single line is important so that version.pm is always loaded when this line is executed by PAUSE or other version extraction tools. And of course, the simpler way to remain compatible with older versions of Perl is to stick to decimal number versions.

Underscores in Versions

Another complex factor in Perl version numbers is the use of underscores. Underscores are, by convention, used to indicate a development or trial release of a module or distribution, which should not be indexed by PAUSE.

For decimal versions, it's mostly straightforward: an underscore is placed somewhere between the digits, and ignored for comparison purposes. However, since these versions look like decimal numbers, some may naively compare them using numeric operators, which will fail if they contain an underscore:

our $VERSION = '0.01_02';
if ($VERSION >= '0.0101') {

This comparison will fail (and throw a non-numeric warning if warnings are enabled) because $VERSION is truncated to '0.01' when used as a number. (A less naive comparison may be performed using the VERSION method or version.pm objects as described later.) To account for this possibility while still leaving the underscore in the declaration for static parsers, a common idiom is to remove the underscore in a following line:

our $VERSION = '0.01_02';
$VERSION =~ tr/_//d;

You may also see eval() used to remove the underscore, but the tr method is more straightforward and preserves trailing zeroes.

Underscores in tuple versions have a significantly more complicated history, and may be interpreted wildly differently depending on the version of version.pm in use. My recommendation would be to avoid doing this entirely, but if you must, your distribution should declare a dependency on version.pm version 0.9915, when its interpretation of underscores in tuple versions was fixed in several ways, and so that it considers underscores in tuple versions the same way as in decimal versions (i.e. not as a separator).

Alternative to Underscore Versions

Rather than using underscores in your versions, there are other mechanisms to indicate a development or trial release of a distribution that don't involve module versions. If the archive file uploaded to CPAN has a name ending in -TRIAL (before the file extensions), PAUSE will not index it as a stable release. Additionally, you can set the release_status metadata field in meta-spec 2; a value of "testing" or "unstable" will indicate that the release should not be indexed. The method of setting this depends on your authoring tool. At the time of writing, either of these methods is sufficient to prevent PAUSE from indexing the distribution, and both are performed automatically by the "--trial" option when releasing using Dist::Zilla or Minilla.

Checking for Versions

With all of this in mind, the safest and most consistent way to check for a particular version of a module is with the UNIVERSAL::VERSION method, which is implicitly used by the use Module::Name VERSION syntax. The VERSION method compares both the module's $VERSION and the passed version as version.pm objects, which automatically does the above-mentioned conversion between version schemes if needed, and throws an exception if the passed version is less than the module version. Like when declaring versions, the version passed to the VERSION method should always be a string or version object.

if (eval { require Module::Name; Module::Name->VERSION('v1.2.3'); 1 }) {
  # Module::Name is able to be loaded and is at least version v1.2.3
}

You can of course use a nicer exception-handling method than bare eval if appropriate.

On Perls older than v5.10.0 you should make sure to 'use version' before doing a comparison involving tuple versions, which will update the VERSION method to use version objects as it does on more recent perls. I would also, as above, recommend depending on version.pm version 0.9915 if you intend to do any comparisons involving versions with underscores.

A more generic method of performing arbitrary version comparisons is to parse the versions into version.pm objects and compare them using standard numeric operators.

use version;
if (version->parse('v1.0.3') == version->parse('1.000003')) {
  # versions are equivalent
}

Versions for Vendors

Perl versions aren't just used within Perl, of course. If you are a CPAN author, you should be mindful that Perl modules from CPAN are packaged for use in various distributions, which primarily use the tuple version format. This doesn't mean you need to use it yourself, but to be polite to those translating your versions, you should follow these simple rules:

If using decimal versions, never decrease the number of significant digits you use without a major version bump. For example, go from '1.19' to '1.20' or '2.0', not to '1.2'.
Never change version schemes without a major version bump. Even if you use the above translation correctly, the package vendor may not, and thus end up with a decreasing version.

Methods to Avoid

There are a couple other ways to declare versions that should be wholly avoided. One is to declare a bare decimal number version, which means you will lose trailing zeroes and possibly encounter floating-point issues. Sometimes this is used because Perl has a feature that looks like underscores in version numbers:

our $VERSION = 0.01_02; # don't do this

However, Perl will immediately compile this to the number 0.0102; underscores in numeric literals are only a visual-aid feature.

Another method with a complicated history is the Perl vstrings feature. This was a feature added in Perl v5.6.0 that seemed to add a convenient syntax for declaring versions that would be stored as a binary string.

our $VERSION = v1.2.3; # don't do this

This example would create a string consisting of three characters, with ordinals 1, 2, and 3, equivalent to the string "\x01\x02\x03" (note: the vstring syntax uses decimal ordinals, but the '\x' syntax uses hexadecimal ordinals). While version.pm does parse and allow vstrings to be used to initialize version objects, their interpretation is inconsistent among older versions of Perl and their implementation is surprising in the context of versions (for instance, they are not numerically comparable), so it's better to just use a string. It turns out vstrings are most useful for creating binary string literals, and not versions.

Perl Perl Versions

As you may notice, the versions of the Perl interpreter itself use the same rules as those for Perl modules. The $] variable is a representation of the version of the current Perl interpreter as a decimal number, and the $^V variable is the version as a version object. From Perl v5.6.0 until Perl v5.10.0 $^V was a vstring rather than a version object, so it's not recommended to use this variable if your code will be running on Perls v5.8.9 or older.

The use VERSION statement and runtime require VERSION allows one to require a certain version of the Perl interpreter using either scheme of version number. Note however that both of these forms require a bareword version rather than a string, and if you use a decimal version form, the three-decimal-places rule still applies; Perl 5.26 would be represented as '5.026', for example.

use v5.14; # also activates feature bundle and strict
use Syntax::Keyword::Try;
try { require v5.26.1; say "Perl is >= v5.26.1" } catch { say "Old Perl: $@" }

Perl 7: A Modest Proposal

Dan — Mon, 08 Feb 2021 02:02:57 +0000

My previous two blog posts (Perl 7: A Risk-Benefit Analysis and Perl 7 By Default) explored the reasons that a Perl 7 with incompatible interpreter defaults would be a mistake. Subsequently, Perl experienced a crisis of governance authority as several core developers also expressed this view. So I will not be further discussing the idea of changing defaults in Perl major versions. But, as I had stated in conclusion:

I believe making good use of a new major version is extremely important to portraying the continued and forward development of Perl to the wider programming community. A major version with major features can be a significant boon to jumpstart the stagnating perception of Perl and bring it in line with the reality of its development.

So then, what should we do? I have some suggestions.

Stable signatures

The widely lauded signatures feature is currently still experimental to facilitate experimentation with several more important features that are needed for it to be considered feature-complete. However, at this point the basic design is well tested and stabilized, and has been unchanged for the requisite two stable releases. I propose that in Perl 7, the signatures feature be declared stable as-is, added to the :7.0 feature bundle, and these further additions to be developed as a separate initiative. The new additions could trigger distinct experimental warnings until stabilized, or be added under one or more new experimental features as appropriate. (Stabilization of the signatures feature has now been proposed by Paul Evans.)

Remove misfeatures

The indirect, multidimensional, and bareword_filehandles features being added in Perl 5.34 (well, indirect is already in Perl 5.32) are "negative" features; the behavior has existed in Perl for quite a while, but the presence of the named features allow disabling them lexically. These misfeatures are not considered best practice and lead to confusing issues, and the ability to disable them, or at least complain loudly upon encountering their use, has been available from CPAN modules for some time; a modern feature bundle should disrecommend their use. I propose removing these three features from the :7.0 feature bundle.

Apply warnings

Since v5.12 or 5.012, the use VERSION keyword has enabled strict alongside the appropriate feature bundle. I propose that Perl 7 finally has use VERSION enable both the recommend strict and warnings pragmas when a version of 7 or higher is requested.

Apply utf8

The utf8 pragma declares that the current source file is encoded in UTF-8 rather than the native single-byte encoding (usually ISO-8859-1). (This is unrelated to functions in that namespace such as utf8::decode as well as other UTF-8 related behavior like that provided by the open pragma.) Zefram previously proposed that this pragma be gradually made default and thus a no-op, to better match the expectations of modern programming. Along with and in anticipation of this step, I propose that Perl 7 has use v7 also do the equivalent of use utf8.

All Together

Declare 'signatures' feature stable as is
Add 'signatures' feature to :7.0 feature bundle
Remove 'indirect', 'multidimensional', and 'bareword_filehandles' negative features from :7.0 feature bundle
Apply effect of 'use warnings' with 'use v7' or higher
Apply effect of 'use utf8' with 'use v7' or higher

Instead of this (note: use v5.32 already includes strict):

use v5.32;
use warnings;
use utf8;
use experimental 'signatures';
no feature qw(indirect multidimensional bareword_filehandles);

New, modern code will simply be able to write:

use v7;

And instead of this:

$ perl -Mstrict -Mwarnings -Mutf8 -Mexperimental=signatures
    -M-feature=indirect,multidimensional,bareword_filehandles
    -E'sub dumphex ($str) { printf "%vX", $str } dumphex "☃"'

Modern oneliners will be able to get the same effect from:

$ perl -M7 -E'sub dumphex ($str) { printf "%vX", $str } dumphex "☃"'

Looking to the Future

We must consider not only what Perl 7 should be, but what Perl should be beyond this milestone. Following from the above proposal for what Perl 7 and use v7 could entail, this naturally leads to a flexible, powerful, and considerate method of promoting stable features and a modern programming environment.

Past feature bundles have been changed rather rarely but at seemingly random versions which are difficult to recall even for the most attentive Perl hacker. Since the introduction of feature bundles in Perl 5.10, they have only changed in 5.12, 5.16, 5.24, and 5.28. Thus my final proposal is that we no longer change feature bundles in arbitrary releases, but only in (true) major versions, which provide significantly more memorable junction points and opportunity for advertisement of these important features.

There are several features currently in the experimental, design, or CPAN prototyping phase that portend to further improve the modern Perl experience, many of which Paul Evans discussed in his FOSDEM 2021 talk:

Any of these features which are not stable and ready for inclusion in a v7 feature bundle, as well as any that are built in the meantime, can be revisited for v8. Each successive major version bundle can continue to promote the best practices of Perl features and help users evolve their usage of modern Perl with a clear, simple declaration. And most importantly, each major version including 7 can be scheduled once a sufficiently exciting new modern feature set is stable and ready to use.

Perl 7 is dead. Long live Perl 7.

Reddit comments