[swift-evolution] Ad hoc enums / options

[Matthew Johnson]

Sent from my iPad

> On Jun 3, 2016, at 10:27 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> If there's any interest in going down that road, it seems to me that the only viable option is to allow subsets to be convertible to their superset. Items of (.foo | .bar) would be convertible to (.foo | .bar | .baz), but not the opposite (and not necessarily, although preferably, through a simple bitcast).

Yes, I suppose in this case implicit convertibility would suffice.  Thanks for bringing it up.  It is effectively a subtype relationship.

> 
> Félix
> 
>>> Le 3 juin 2016 à 16:20:18, Greg Parker via swift-evolution <swift-evolution at swift.org> a écrit :
>>> 
>>> 
>>>> On Jun 1, 2016, at 5:42 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>>> On Jun 1, 2016, at 5:02 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> in other words, we could consider allowing this:
>>>>>   func foo(bar: (.fit | .fill)) {
>>>>>     baz(bar: bar)
>>>>>   }
>>>>>   func baz(bar: (.fit | .fill | .florp) { ... }
>>>>> 
>>>>> In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
>>>>> expected if T ⊆ U.
>>>> 
>>>> Can't agree with this. Just because the same analogue with tuples : differently defined tuples are different types. Tuples with different order of types in declaration - are different types. So I expect here instance of (.fit | .fill) `bar` is not of the same type as (.fit | .fill | .florp)
>>> 
>>> They are not the same type but there is a structural subtype relationship between them.  All values of type (.fit | .fill) are also values of type (.fit | .fill | .florp).
>> 
>> What about disjoint types? Some values of type (.fit | .fill) are values of type (.fit | .florp) and some are not. I'm not a type system expert but my understanding is that this capability gets very complicated very fast.
>> 
>> 
>> 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.
>> 
>> An implementation like ObjC's @selector or C/C++ weak definition would work, but those are expensive in memory overhead and launch time. 
>> 
>> You could give each linkage unit its own copy of the value that includes a string of the value's name plus an == operator that compares the name strings; that would avoid uniquing but would make some operations slow. 
>> 
>> In any case the performance of these things will not be comparable to ints nor to typical Swift enums that are encoded as ints.
>> 
>> 
>> -- 
>> Greg Parker     gparker at apple.com     Runtime Wrangler
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160604/10f63044/attachment.html>