Sent from my iPad
> On Jun 3, 2016, at 6:20 PM, Greg Parker <gpar...@apple.com> wrote:
>
>
>>> On Jun 1, 2016, at 5:42 PM, Matthew Johnson via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>>> On Jun 1, 2016, at 5:02 PM, Vladimir.S via swift-evolution
>>>> <swift-evolution@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.
It feels like the only sane way to model these is as union types where each
member of the union has a single literal value like '.fit'. This is where
structural subtyping would come from.
In your example I would say there is no subtype relationship there, just as a
union of 'Fit | Fill' would not have any subtype / supertype relationship with
'Fit | Florp' in a language like Ceylon that has union types.
Without the structural subtyping these types would be way too fragile to be
considered IMO.
>
>
> 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.
You bring up very good points. I'm not saying we *should* do this. Only that
if we do introduce ad-hoc enums this seems like the only sane way to do it. I
would want to be able to declare declare variables, etc that use the type
without having every mention of the type break when the author of the function
adds a new option.
My opinion is that everything you bring up is a pretty solid argument against
ad-hoc enums. Maybe is Swift ever gets union types we could revisit the idea
under that umbrella (but that is sounding unlikely, and is definitely not
something that will happen soon).
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
