[Pitch] `@OptionSet` macro

Evolution Pitches
116

-0.75 from me for these reasons:

  • As the Swift API guidelines state, we should favour clarity over brevity. It is not immediately apparent one is declaring an OptionSet, but an enum inside a struct. I would argue that the bit shifting on static lets is more readable than an enum and make an optionset very quickly recognisable from normal structs. More so, the default Xcode colour scheme makes some @ markers easy to miss (property wrappers especially so). I don’t know how Xcode will eventually color macros but we can’t rely on any IDE to visually help discovery. It’s also yet another @ Why so many "@" expressions?
  • OptionSets are too rare to warrant a macro in the standard library. They’re a “niche” language feature if you will that is only used in environments where performance and storage are amazingly important - very low level programming, embedded systems etc. A large proportion of swift developers never create their own option sets. The ones that do, I'm not convinced they particularly need a macro for it in the standard library. Most run of the mill optionsets are not so large that they get hard to read.
  • The original proposal and all the variants in this thread don’t shorten the code needed to write an optionsset, some of them enlarge it

Addition to the standard library checklist:

  • Does this solve a common problem?
    • No
  • Does it make code more readable?
    • No
  • Is this flexible enough?
    • Not in the original form, but the thread exposed some possibilities for flexibility however those made the code even more unreadable
  • Does it help write correct code?
    • Yes
  • Can it avoid performance problems?
    • --

All in all I don’t think the macro is so useful that it needs to be part of the standard library and it is very clear that addition of a new type or keyword is undesirable. I personally don’t understand why we can’t have some syntactic sugar for this the same way Int? is syntactic sugar for Optional<Int>. If the private enum could have been written as “options x, y, z” just as pure syntactic sugar then perhaps this would be a lot more readable

7 Likes