Why dosen't => quote barewords with ::?

[MrNobo1024]

This one-liner

perl -e 'use strict; my %foo = (Bar::Baz => "qux")'

produces the error

Bareword "Bar::Baz" not allowed while "strict subs" in use at -e line 
+1.
Execution of -e aborted due to compilation errors.

I thought => was supposed to quote barewords? Has the behaviour of this changed since 5.6? There are a few modules that do something like

use strict;
use Attribute::Handlers autotie => { __CALLER__::Attribute => __PACKAG
+E__ };

and I had to quote __CALLER__::Attribute to get it to work on 5.8.

--MrNobo1024
s]]HrLfbfe|EbBibmv]e|s}w}ciZx^RYhL}e^print

[Abigail-II]

It's a bug. It works ok in 5.6.1. From perldata:

       It is often more readable to use the "=>" operator between
       key/value pairs.  The "=>" operator is mostly just a more
       visually distinctive synonym for a comma, but it also
       arranges for its left-hand operand to be interpreted as a
       string--if it's a bareword that would be a legal identi-
       fier.

Bar::Baz is a valid identifier.

I'll perlbug it.

Abigail

[kvale]

From the 5.8.0 docs:

The => digraph is mostly just a synonym for the comma 
operator.  It's useful fordocumenting arguments that 
come in pairs.  As of release 5.001, it also forces
any word to the left of it to be interpreted as a string.

It appears that 5.8.0's idea of a word does not include colons.

-Mark

[Zaxo]

Stringy comma's idea of a word is the same as \w+ in a regex, /^[0-9A-Z_a-z]+$/.

Update: fixed typo, ++tadman for spotting it.

After Compline,
Zaxo

[demerphq]

Actually id say that that regex is not quite right. First of all this comes down to the defintion of a bareword, which isnt well defined from what ive read. But if we must discuss a regex for this purpose I would say it would be more like the following, but even then its not _entirely_ clear (the issue of v strings rears its head as well as a few other issues)

/^\s*([-A-Z_a-z][A-Z_a-z0-9]*|\d+)\s*/

(Im debating the \s* bit. Ive put it in becuase of Juerds comment below, but on reflection I dont actually think its necessary as the tokenizer would be remove the whitespace the surrounds the token preceeding the => digraph before the parser even saw the digraph.)

To be honest IMO there isnt an exact regex. The rules of the tokenizer are not representable by a regex as far as I know. (I could be wrong, it happens a lot. :-)

Some bizarre examples:

use strict;
use warnings;

local $\="\n"; local $,="\t";
print Zaxo => 'Juerd';
print Zax0 => Ju3rd => 'Foo';
print -abcde=>'foo';
print v9.100.101.109.101.114.112.104.113.9 => v65; 
print 0 => 'foo';
print v48.65 => 'A0';
print 0x00 => 'foo';  #prints 0 not 0x00
# print 1a2b => 'foo'; #doesnt work, cant have alphas when the key sta
+rts with a digit (0x excepted)
# print 1a-2b => 'foo'; #doesnt do what you might think, evals to 0

Anyway, if you are interested in this , there is currently a discussion on p5p about the behaviour of => (started by Abigail-II) called

[perl #16010] v-strings left of a => don't get quoted.

It seems the issues of => and v strings are quite convoluted. :-)

Yves / DeMerphq
---
Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)

[Juerd]

 /^[0-9A-Z_a-z]+$/

 /^[0-9A-Z_a-z]+\z/, because $ matches before \n if present. \z is end of string.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.