Sent from my iPad
> On Jun 3, 2016, at 10:27 PM, Félix Cloutier <[email protected]> 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 >>> <[email protected]> a écrit : >>> >>> >>>> On Jun 1, 2016, at 5:42 PM, Matthew Johnson via swift-evolution >>>> <[email protected]> wrote: >>>> >>>>> On Jun 1, 2016, at 5:02 PM, Vladimir.S via swift-evolution >>>>> <[email protected]> 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 [email protected] Runtime Wrangler >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
