Given the potential for confusion that has been shown from Indirect Object Syntax, it seems that this is another place where confusion could arise.
I think there is a significant difference though: For indirect object syntax, Perl has to use heuristics that are also based on things not near the piece of code being parsed (spooky action at a distance), so that when encountering e.g. new File $path, $data, both perl and the human reading the code have to "guess" as to what was meant. For hash keys on the other hand, the rules for what is autoquoted are clear, so the only potential for confusion is on the side of the programmer not knowing the autoquoting rules. $hash{key} is always the same as $hash{"key"}, no matter if the bareword key is also a filehandle, sub, package name, etc. - but OTOH, for example $hash{a b} is not the same as $hash{"a b"}, which is sometimes surprising to coders. Further reading:
In fact, a simple identifier within such curlies is forced to be a string, and likewise within a hash subscript. Neither need quoting. Our earlier example, $days{'Feb'} can be written as $days{Feb} and the quotes will be assumed automatically. But anything more complicated in the subscript will be interpreted as an expression. This means for example that $version{2.0}++ is equivalent to $version{2}++, not to $version{'2.0'}++.
The => operator (sometimes pronounced "fat comma") is a synonym for the comma except that it causes a word on its left to be interpreted as a string if it begins with a letter or underscore and is composed only of letters, digits and underscores. This includes operands that might otherwise be interpreted as operators, constants, single number v-strings or function calls. If in doubt about this behavior, the left operand can be quoted explicitly.
Minor edits for clarity.
In reply to Re: Quoting hash keys
by haukex
in thread Quoting hash keys
by Bod
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |