in reply to Re^2: Hash keys not DWIMming
in thread Hash keys not DWIMming

I'm not arguing against your statement: "The fat comma doesn't follow different rules of autoquoting than hash keys do.".

However, the target of autoquoting may be handled differently prior to autoquoting.

Here's an example with constants:

$ perl -wE 'use constant XXX => q{a}; my %x = (XXX() => 123); say $x{X +XX()};' 123 $ perl -wE 'use constant XXX => q{a}; my %x = (XXX() => 123); say $x{+ +XXX};' 123 $ perl -wE 'use constant XXX => q{a}; my %x = (+XXX => 123); say $x{XX +X()};' Use of uninitialized value in say at -e line 1. $ perl -wE 'use constant XXX => q{a}; my %x = (+XXX => 123); say $x{+X +XX};' Use of uninitialized value in say at -e line 1.

Note how both XXX() and +XXX can be used as the hash key but only XXX() works on the LHS of the fat comma.

This example is run under 5.12.0 but I recall the same behaviour under 5.8 (definitely) and 5.6 (probably).

I have a vague recollection that there's another instance of this type of behaviour but I can't think what it is right now.

-- Ken

Replies are listed 'Best First'.
Re^4: Hash keys not DWIMming
by JavaFan (Canon) on Oct 08, 2010 at 10:04 UTC
    Note how both XXX() and +XXX can be used as the hash key but only XXX() works on the LHS of the fat comma
    Note that neither XXX() nor +XXX is quoted as a hash key - what is between the parens isn't a bare word. In all cases, the key is "a".

    There's nothing to autoquote in XXX() => 123 as there's no bare word directly left of the arrow. However, in +XXX => 123 there is a bare word left of the arrow: hence it's tokenized as +"XXX", 123.