Cavet: I have not been following this, so probably someone has said this somewhere and flaws were pointed out.
I don’t really understand the need for union types when you can have multiple methods of the same name that differ only by the type of their parameter: func something(value: A) {} func something(value: B) {} func something(value: C) {} Doesn’t this more or less accomplish the same thing without needing a switch/if tree or whatever else inside the method to break the types back apart again in the method body and without even needing any new mechanism in the language at all? Again, sorry for the (very likely) redundant noise on my part. l8r Sean > On May 17, 2016, at 6:09 PM, Leonardo Pessoa via swift-evolution > <swift-evolution@swift.org> wrote: > > Jiannan, I agree there is an use for union types, I'm just not really fond of > the syntax (I'd really prefer something like 'union<...>') and with using it > for optionals. To enable this syntax for optionals, None would have to be a > valid type of the language and that would enable one to create the following > constructions: > > func something(value: None) -> None { ... } > > It wouldn't be essentially wrong but unnecessary since nil would be the only > possible value of the type None. And I don't really see any need to change > the way optionals are implemented to support unions. And we could still have > optional unions using either syntax with existing optional syntax (which is > very clear to me): > > func something(value: (A | B | C)?) { ... } > > or > > func something(value: union<A, B, C>?) { ... } > > Just as I said before, I don't really think unions are necessary (did you > mean overloading?) but I don't oppose them. I just don't think we need to > change the way a feature already works to justify the addition of a new > feature. > > > - Leonardo > > On 16 May 2016 at 08:26, Cao Jiannan via swift-evolution > <swift-evolution@swift.org> wrote: > Union is far better then generic enum/protocol solution. > * It can extend the original enum and make it powerful. > > enum ResultDataType { > case Music > case Video > case File > } > > enum FailureType { > case HTTP404 > case HTTP502 > } > > enum FailureTypev2 { > case HTTP451 > } > > typealias Result = (ResultDataType | FailureType | FailureTypev2) > > * It keeps the code clear and does not need developer to announce some > unnecessary protocols or enums. > like UnionOf3<T,U,V> or ProtocolForABC > > * It is easy to wrap original value into an union type. > let a = A() > let union: (A|B|C) = a // Automatically wrap. > > * Compiler might search their common properties, and methods, then mark > them as a member of the union type. > print(value.someCommonProperty) // Compiler will know their > common properties automatically. > > > * Compiler know the union type exactly composed with which types, > better than only know which protocol. > func input(value: ProtocolForABC) { > if value is A { > > } else if value is B { > > } else if value is C { > > } else { > // There are other cases? Compiler doesn't know > } > } > > * Original types and union types can have a rational relationship > between each other. > Original type is a sub-type of union types contain it. > > var fn0: A->Void = {print(v0)} > var fn1: (A|B)->Void = {print(v0)} > > fn0 = fn1 // Original Type and Union Type has a sub-typing > relationship, OK > > var fn2: (A|B|C)->Void = {print($0)} > > fn0 = fn2 // OK > fn1 = fn2 // OK > > > * It is also easy to compare with value of original type. > union == a // Can be compared, Yes for most cases. > > * And the most important part, It can replace Optional<T>. > let string: String? > is same to > let string: (String | None) instead of let string: > Optional<String> > > > I really think the union type is a good supplement for Swift. Make the > language rational. > And the It is also really good for Reactive Programming. > > - Jiannan > >> 下面是被转发的邮件: >> >> 发件人: Haravikk <swift-evolut...@haravikk.me> >> 主题: 回复: [swift-evolution] Union instead of Optional >> 日期: 2016年5月16日 GMT+8 18:35:25 >> 收件人: Austin Zheng <austinzh...@gmail.com> >> 抄送: Cao Jiannan <frog...@163.com>, Adrian Zubarev via swift-evolution >> <swift-evolution@swift.org> >> >> >>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution >>> <swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution