[swift-evolution] Ad hoc enums / options

[Erica Sadun]

> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution <swift-evolution at swift.org> wrote:
> What about the ABI? This sounds expensive to implement.
> 
> Consider this set of ad-hoc enum types:
> 
>   (.a | .b)
>   (.c | .d)
> 
> Naive implementation: we'll represent these things as ints, with .a=1, .b=2, .c=1, .d=2.
> 
> The naive implementation breaks when a newly-loaded shared library or some library evolution adds this type:
> 
>   (.a | .b | .c | .d)
> 
> In order to provide ABI stability in the face of arbitrary ad-hoc enum types we must ensure that every ad-hoc enum value has a globally unique ABI representation. 
> 
> You could constrain ad-hoc enum values to module or class boundaries and prevent creation of types that use values from different places. For example, if Foundation defines (.a | .b) then you can't define your own ad-hoc enum (.a | .b | .c) that is compatible with Foundation's value for .a. Then the implementation could use ordinary symbols. If usage of ad-hoc enums is not constrained then ordinary symbols don't work because there is no universally agreed-upon place where .a is defined.

In my mind, the ad hoc enum must be tied to a specific function or method signature. In doing so, it has a unique module/selector associated with it, so it's not just .a but rather Foo.funcname.a (assuming no more than one ad hoc enum per function) or Foo.funcname.3.a (assuming its the third parameter of the selector). The conversation has drifted a bit from my request.

If the enum needs to be used in more situations, it needs to be a proper enum because the semantics are tied to a higher level of visibility.

I'm striving for enhanced readability in intent (for example, where !x is a poor description of the option other than x, or even when there are >2 options that will never be used elsewhere such as fill, fit, scale) and in expression (choosing self-annotating switch statements over if statements, where its clear what each branch intends to do).

These enums would be limited to basic hashValue types, and would appear in QuickHelp as annotations of legal values to supply to the argument. My intent is that there never be more than 3-5 enumeration cases used in this anonymous fashion.

-- E