I like the justification of unions as lightweight restricted ad-hoc enums. Definitely agreed with you in that the compiler will have to do more work, and should be able to handle the implicit conversion without going bonkers.
Thanks! Austin > On May 16, 2016, at 3:35 AM, Haravikk <[email protected]> wrote: > > >> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution >> <[email protected]> wrote: >> >> If A, B, and C are not related via protocol or class inheritance, then there >> is almost nothing you can do with value. Otherwise you still need to test >> against the concrete type using a case statement or a if-else ladder. > > I think that a case statement or similar syntax will still be needed, and the > case names would just be the types themselves. This would work best with > support for type-narrowing, for example: > > func someMethod(value:(A|B|C)) { > switch (value) { > case .A: > value.someMethodForTypeA() > case .B: > value.someMethodForTypeB() > case .C: > value.someMethodForTypeC() > } > } > > A union should really just be though of as a lightweight, restricted form of > enum that can be declared in a quick ad-hoc fashion, similar to how tuples > are a simpler form of struct. > > I’m generally a +1 for the feature, but I’d be interested to hear about how > well equipped the compiler is for optimising something like this. In most > cases an Optional covers what I need, and in more complex cases I’d probably > declare overloads for each type (i.e- someMethod(value:A), > someMethod(value:B) etc.); unions could make the latter case simpler, but > will the compiler produce the same code behind the scenes, i.e- by isolating > what’s unique to each type? _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
