I like the idea of this becoming a macro, but like others here, I'm not a fan of needing the nested type to provide the basic option set. Types leave metadata behind that's still as of yet hard for the compiler and linker to reliably strip away, and if the author of an option set doesn't remember to make the seed option enum private, it seems like could become a point of confusion in the API for their coworkers. If attached macros are able to recognize the use of other macros within the body, would it be possible to do something like:
@OptionSet struct ShippingOptions {
@Option static var nextDay, secondDay, priority, standard
}
where the @Option annotation takes care of doling out raw values for the options, and choosing the appropriate underlying bits type? That seems to me like it gets fairly close to your "first-class optionset declaration", while still also being less indirect than the proposed behavior, since the author of the code is still directly declaring the static vars that make up the API of the type. An approach like this also lets developers control access to individual options, as in:
@OptionSet public struct ShippingOptions {
@Option public static var nextDay, secondDay, priority, standard
@Option private static var topSecretTeleportation
}
which doesn't seem possible using a separate type to derive the options.