Open Radar

 
Summary:
bitmask types defined using NS_OPTIONS do not agree with what the documentation specifies.  We will use NSRegularExpressionOptions as an example.  The documentation specifies:

enum {
   NSRegularExpressionCaseInsensitive             = 1 << 0,
   NSRegularExpressionAllowCommentsAndWhitespace  = 1 << 1,
   NSRegularExpressionIgnoreMetacharacters        = 1 << 2,
   NSRegularExpressionDotMatchesLineSeparators    = 1 << 3,
   NSRegularExpressionAnchorsMatchLines           = 1 << 4,
   NSRegularExpressionUseUnixLineSeparators       = 1 << 5,
   NSRegularExpressionUseUnicodeWordBoundaries    = 1 << 6
};
typedef NSUInteger NSRegularExpressionOptions;

That is, NSRegularExpressionOptions is an unsigned integer.

Meanwhile, the header actually specifies (through NS_OPTIONS)
typedef enum : NSUInteger {
   NSRegularExpressionCaseInsensitive             = 1 << 0,
   NSRegularExpressionAllowCommentsAndWhitespace  = 1 << 1,
   NSRegularExpressionIgnoreMetacharacters        = 1 << 2,
   NSRegularExpressionDotMatchesLineSeparators    = 1 << 3,
   NSRegularExpressionAnchorsMatchLines           = 1 << 4,
   NSRegularExpressionUseUnixLineSeparators       = 1 << 5,
   NSRegularExpressionUseUnicodeWordBoundaries    = 1 << 6
} NSRegularExpressionOptions;

These two declarations are not equivalent.  One creates a type synonym, the other creates a new type with only 7 values in it (although backed by an unsigned integer).  This means that with the declaration used in the header 0 is not a value in the type (but happens to work with the current implementation), so it is impossible to specify no options at all.  It would be entirely valid for the compiler to warn (or error) about values other than the 7 specified in the enum, or to produce undefined behaviour when other values are used.