[swift-evolution] A native option set construct

[Joe Groff]

> On Dec 21, 2015, at 2:38 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> One of the things that surprised me is that there still isn’t concise syntax for creating option sets, a pattern I see out in the wild a fair bit.  While Swift 2 did introduce OptionSetType for structs, it still feels somewhat obtuse and non-obvious.  It would be great if we could something like:
>> 
>> options NotSoSecretVariations {
>> 	case ProteinStyle,
>> 	case AnimalStyle,
>> 	case GrilledOnions,
>> 	...
>> }
>> 
>> That said, I have a feeling this isn’t the first time the Swift team has come across a pitch like this.  If this really is unfeasible, it would be great and really educational to hear what the challenges are.
> 
> Personally, what I'd like to see is the concept of an option separated from that of an option *set*. Once you do that, you can define an individual option simply using an enum, and let the set handle combining the options together.
> 
> Here's what I mean. Take an Objective-C NS_OPTIONS enum:
> 
> 	typedef NS_OPTIONS(NSUInteger, NSStringCompareOptions) {
> 	    NSCaseInsensitiveSearch = 1,
> 	    NSLiteralSearch = 2,		/* Exact character-by-character equivalence */
> 	    NSBackwardsSearch = 4,		/* Search from end of source string */
> 	    NSAnchoredSearch = 8,		/* Search is limited to start (or end, if NSBackwardsSearch) of source string */
> 	    NSNumericSearch = 64,		/* Added in 10.2; Numbers within strings are compared using numeric value, that is, Foo2.txt < Foo7.txt < Foo25.txt; only applies to compare methods, not find */
> 	    NSDiacriticInsensitiveSearch NS_ENUM_AVAILABLE(10_5, 2_0) = 128, /* If specified, ignores diacritics (o-umlaut == o) */
> 	    NSWidthInsensitiveSearch NS_ENUM_AVAILABLE(10_5, 2_0) = 256, /* If specified, ignores width differences ('a' == UFF41) */
> 	    NSForcedOrderingSearch NS_ENUM_AVAILABLE(10_5, 2_0) = 512, /* If specified, comparisons are forced to return either NSOrderedAscending or NSOrderedDescending if the strings are equivalent but not strictly equal, for stability when sorting (e.g. "aaa" > "AAA" with NSCaseInsensitiveSearch specified) */
> 	    NSRegularExpressionSearch NS_ENUM_AVAILABLE(10_7, 3_2) = 1024    /* Applies to rangeOfString:..., stringByReplacingOccurrencesOfString:..., and replaceOccurrencesOfString:... methods only; the search string is treated as an ICU-compatible regular expression; if set, no other options can apply except NSCaseInsensitiveSearch and NSAnchoredSearch */
> 	};
> 
> I think this should be translated to Swift like this:
> 
> 	enum NSStringCompareOption: Int {
> 	    case CaseInsensitiveSearch = 0	// Because 1 << 0 == 1
> 	    case LiteralSearch = 1	// 1 << 1 == 2
> 	    case BackwardsSearch = 2
> 	    case AnchoredSearch = 3
> 	    case NumericSearch = 6	// 1 << 6 == 64
> 	    case DiacriticInsensitiveSearch = 7
> 	    case WidthInsensitiveSearch = 8
> 	    case ForcedOrderingSearch = 9
> 	    case RegularExpressionSearch = 10
> 	}
> 
> Meanwhile, a method taking NSStringCompareOptions like this:
> 
> 	- (NSComparisonResult)compare:(NSString *)string options:(NSStringCompareOptions)mask;
> 
> Should be translated as:
> 
> 	func compare(string: NSString, options mask: OptionSet<NSStringCompareOption>) -> NSComparisonResult
> 
> OptionSet would be a generic type like this:
> 
> 	struct OptionSet<Option: RawRepresentable where Option.RawValue: IntegerType>: SetAlgebraType, RawRepresentable {
> 	    typealias Element = Option
> 	    typealias RawValue = Option.RawValue
> 	    ...
> 	}
> 
> This definition should work for any NS_OPTIONS where the options are non-overlapping. I'm not sure if that's *every* option set in the Apple frameworks, but I think it's the vast majority of them. (The incompatible ones could use the existing mechanism.) And to create your own option set, all you have to do is write an enum with an integer raw type that has less than 32 or 64 cases, depending on your target. You don't even have to specify the raw values—the default ones will work fine.

One reason we preserved the NS_OPTIONS model, where single options share the same type as option sets, is that it allows for API evolution. A library can break a single option down into multiple refined options while still offering the original option as the union of the new ones. So you can go from:

public struct LaundryOptions: OptionSetType {
  public static let EnergyStar = 1
}

to:

public struct LaundryOptions: OptionSetType {
  public static let EnergyStar: LaundryOptions = [.LowWater, .LowHeat]
  public static let LowWater = 1, LowHeat = 2
}

without breaking client code (or at least, client code that doesn't attempt to inspect the option set itself).

-Joe