Smart matching in v5.10 led to several broken and conflated features. The given used a lexical version of $_, which broke many other common uses of that variable inside the given, which I explain in Use for() instead of given() and you can see in given/when and lexical $_ ….

Under v5.18, when you use given, when, or ~~, you get a warning, even if there is no smart match involved:

# given_warning.pl
use v5.10; # earliest occurance of feature
for( 'Buster' ) {
	when( 1 == 1 ) { say "Hello" }
	}

These warnings might cause test suites to fail when people try to install modules on the new perl, like it does for Unicode::Tussle.

% perl5.10.1 given_warning.pl
Hello
% perl5.18.0 given_warning.pl
when is experimental at given_warning.pl line 4.
Hello

Using the diagnostics shows the sort of warning it is:

% perl5.18.0 -Mdiagnostics given_warning.pl
when is experimental at -e line 1 (#1)
    (S experimental::smartmatch) when depends on smartmatch, which is
    experimental.  Additionally, it has several special cases that may
    not be immediately obvious, and their behavior may change or
    even be removed in any future release of perl.
    See the explanation under "Experimental Details on given and when"
    in perlsyn.

Hello

To get rid of this warning, you do the same thing you do with other warnings. Take the category of the warning and turn it off with no (Item 100: Use lexical warnings to selectively turn on or off complaints):

# given_warning.pl
use v5.10; # earliest occurance of feature
no warnings 'experimental::smartmatch';
for( 'Buster' ) {
	when( 1 == 1 ) { say "Hello" }
	}

The lexical $_ is another broken fature that’s now marked as experimental.

# lexical_.pl
use v5.10;

sub cat { my $_ }

Any use in v5.18 gives a warning:

% perl5.18.0 lexical_.pl
Use of my $_ is experimental at lexcial_.pl line 3.

The category is different:

% perl5.18.0 -Mdiagnostics lexical_.pl
Use of my $_ is experimental at lexcial_.pl line 4 (#1)
    (S experimental::lexical_topic) Lexical $_ is an experimental
    feature and its behavior may change or even be removed in any
    future release of perl. See the explanation under "$_" in perlvar.

That takes care of the two retro features. Perl v5.18 introduces two new experimental features, set logic in character classes (for complete Unicode Level 1 regular expression compliance), and lexical subroutines, which I’ll cover in other items.

# regex.pl
use v5.18;

print "Match" if 'foo' =~ /(?[ \p{Thai} & \p{Digit} ])/;

Without turning off the warning, perl knows about the feature and points it out:

% perl5.18.0 regex.pl
The regex_sets feature is experimental in regex; marked by <-- HERE in m/(?[ <-- HERE  \p{Thai} & \p{Digit} ])/ at regex.pl line 4.

In this case, diagnostics is not any help:

% perl5.18.0 -Mdiagnostics regex.pl
The regex_sets feature is experimental in regex; marked by <-- HERE in m/(?[
        <-- HERE  \p{Thai} & \p{Digit} ])/ at regex.pl line 3 (#1)
The regex_sets feature is experimental in regex; marked by <-- HERE in m/(?[ <-- HERE  \p{Thai} & \p{Digit} ])/ at regex.pl line 3.

For lexical named subroutines, you have explicitly enable the feature but you then have to explicitly turn off its warnings.

# lexical_sub.pl
use v5.18;
no warnings 'experimental::lexical_subs';
use feature "lexical_subs";

my sub foo { say "Hello" }

Handling older perls

In v5.18, that's all fine and good, but older versions don't understand those warnings categories and will stop your program.

% perl5.10.1 -e 'no warnings qw(smartmatch)'
Unknown warnings category 'smartmatch' at -e line 1
BEGIN failed--compilation aborted at -e line 1.

Instead of using warnings, you can use the non-core experimental module that handles that for you:

use experimental qw(smartmatch);

For versions without that warning category, nothing happens. For versions with that feature, it turns off the warning.

Summary

This table summarizes the new experimental warnings categories and the features they affect.

Things to remember

• Some v5.10 features now warn under v5.18
• Some new experimental features must be explicitly enabled
• Even explicitly enabled features still warn
• The experimental module is version safe

• Experimental features now warn (reaching back to v5.10)
• Perl regex character classes now have set operations
• Labels can be computed
• \s now matches the vertical tab
• given now aliases $_ like foreach does
• readline now reads characters instead of octets
• CPANPLUS and Archive::Extract are deprecated and marked for removal in v5.20.
• The ${^LAST_FH} refers to the last filehandle.

I had this program to mark which sets matched which characters. I required v5.10 because that’s the first appearance of the \h and \v shortcuts for horizontal and vertical whitespace.

use 5.010;

use charnames qw(:full);

print <<"LEGEND";
s   matches \\s, matches Perl whitespace
h   matches \\h, horizontal whitespace
v   matches \\v, vertical whitespace
p   matches [[:space:]], POSIX whitespace
all characters match Unicode whitespace, \\p{Space}

LEGEND

printf qq(%s %s %s %s  %-7s --> %s\n),
	qw( s h v p  Ordinal  Name );
print '-' x 50, "\n";

foreach my $ord ( 0 .. 0x10ffff ) {
	next unless chr($ord) =~ /\p{Space}/;
	my( $s, $h, $v, $posix ) =
		map { chr($ord) =~ m/$_/ ? 'x' : ' ' }
			( qr/\s/, qr/\h/, qr/\v/, qr/[[:space:]]/ );
	printf qq(%s %s %s %s  0x%04X  --> %s\n),
		$s, $h, $v, $posix,
		$ord, charnames::viacode($ord);
	}

Under v5.10, the top of the output showed that \s did not include the vertical tab, which the UCS names LINE TABULATION.

$ perl5.10.1 spaces
s   matches \s, matches Perl whitespace
h   matches \h, horizontal whitespace
v   matches \v, vertical whitespace
p   matches [[:space:]], POSIX whitespace
all characters match Unicode whitespace, \p{Space}

s h v p  Ordinal --> Name
--------------------------------------------------
x x   x  0x0009  --> CHARACTER TABULATION
x   x x  0x000A  --> LINE FEED
    x x  0x000B  --> LINE TABULATION
x   x x  0x000C  --> FORM FEED
x   x x  0x000D  --> CARRIAGE RETURN
x x   x  0x0020  --> SPACE

Run under v5.18, the output changes slightly to have another x in the third row (line 12).

$ perl5.18.0 spaces
s   matches \s, matches Perl whitespace
h   matches \h, horizontal whitespace
v   matches \v, vertical whitespace
p   matches [[:space:]], POSIX whitespace
all characters match Unicode whitespace, \p{Space}

s h v p  Ordinal --> Name
--------------------------------------------------
x x   x  0x0009  --> CHARACTER TABULATION
x   x x  0x000A  --> LINE FEED
x   x x  0x000B  --> LINE TABULATION
x   x x  0x000C  --> FORM FEED
x   x x  0x000D  --> CARRIAGE RETURN
x x   x  0x0020  --> SPACE

I don’t foresee this breaking anything since the vertical tab seems to be a rare character, although in ETL I liked using it as a separator since I figured no one else would be using it.

If you can’t make it to OSCON, you can still get 35% off the cover price by ordering directly from the InformIT discount link or using the OSCON2012 discount code when you check out. Instead of navigating their site, you can go directly to our book.

If you’re not sure you want the book, you can look at a free sample chapter, which is also 35% off during OSCON.

#   Failed test 'POD test for blib/lib/Mac/Errors.pm'
#   at .../Test/Pod.pm line 182.
# blib/lib/Mac/Errors.pm (2776): Non-ASCII character seen before =encoding in 'donÍt'. Assuming ISO8859-1
# Looks like you failed 1 test of 2.
t/pod.t ...........
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests

Unfortunately, the Pod tests are the sort that shouldn’t stop an installation, which is why many developers have a separate area for author tests (which I’ll cover in an upcoming Item). Outside of that, you have to fix the Pod.

There are two things here. First, I have a genuine error here. The module is auto generated from other source files and the “donÍt” is a mistake; it should be “don’t” (with a smart quote) or even better, “don’t”. Test::Pod didn’t catch this before. So, that’s not bad.

More importantly, telling Perl that the source code is UTF-8 isn’t enough. When you use the utf8 pragma, the perl interpreter reads the source as UTF-8:

use utf8;

However, a Pod parser ignores all the code. It looks for Pod sections and never sees that pragma, nor does it care. You have to tell the pod which encoding you have if you want to use something outside of ASCII:

=encoding utf8

I hadn’t used that in Mac::Errors, or any of my other modules, although in some of them I had used genuine UTF-8 sequences. Now any person using Test::Pod with the latest Pod::Simple won’t be able to install those modules normally. That is, until I fix them.

I could use other encodings, such as ISO-8859-1, as long as I declare the right thing and save the file correctly.

Things to remember

• The utf8 pragma doesn’t affect the Pod
• Pod::Simple assumes ASCII unless you tell it otherwise
• Declare your Pod encoding with the =encoding directive