The BITMASK option allows the easy creation of bitmask constants such as functions like flock() and sysopen() use. These are also very useful for your own code as they allow you to efficiently store many true/false options within a single integer.

When using bitmasks, remember that you must use the bitwise operators, |, &, ^, and ~. If you try to do an operation like $foo += MY_DOG; and the MY_DOG bit has already been set, you'll end up setting other bits you probably didn't want to set. You'll find the documentation for these operators in the perlop manpage.

You can set a starting index for bitmasks just as you can for normal enum values, but if the given index isn't a power of 2 it won't resolve to a single bit and therefor will generate a compile error. Because of this, whenever you set the BITFIELD: directive, the index is automatically set to 1. If you wish to go back to normal enum mode, use the ENUM: directive. Similarly to the BITFIELD directive, the ENUM: directive resets the index to 0. Here's an example:

Enum names can not be the same as method, function, or constant names. This is probably a Good Thing[tm].

No way (that I know of) to cause compile time errors when one of these enum names get redefined. IMHO, there is absolutely no time when redefining a sub is a Good Thing[tm], and should be taken out of the language, or at least have a pragma that can cause it to be a compile time error.

Enumerated types are package scoped just like constants, not block scoped as some other pragma modules are.

It supports A..Z nonsense. Can anyone give me a Real World[tm] reason why anyone would ever use this feature...?