> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution 
> <[email protected]> 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


_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to