That's exactly my point, Sean. - Leonardo
On 17 May 2016 at 20:31, Sean Heber <s...@fifthace.com> wrote: > 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