Enums with associated types in Swift are the equivalent of unions, even if they don’t have the name. I don’t see what your proposal is trying to solve?
> On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution > <swift-evolution@swift.org> wrote: > > > It’s kind of same idea of TypeScipt 2, at 46:21 in this video. > > https://channel9.msdn.com/Events/Build/2016/B881 > <https://channel9.msdn.com/Events/Build/2016/B881> > > <屏幕快照 2016-05-15 10.20.36.png> > > >> >> 2016-2-16 GMT+8 14:36:28 >> Hi all, >> >> I think the best way to solve the either problem is to separate it from >> generic. >> Optional and Either shouldn’t work the same way of generic type. >> It’s just a represent of multiple type in one location. >> >> Using an old friend, Union in C. >> union { >> case firstType >> case secondType >> } >> >> This is the final solution for the sub typing problem of optional. >> >> A == union(A,A) >> union(A,B) == union(B,A) >> B == union(B,B) >> >> B is subtype of union(A,B) >> A is subtype of union(A,B) >> union(A,B,C) is subtype of union(A,B,C,D,…) >> >> suppose >> a is subclass of A >> b is subclass of B, then >> union(a,B) is subtype of union(A,B) >> union(A,b) is subtype of union(A,B) >> union(a,b) is subtype of union(a,B) >> union(a,b) is subtype of union(A,b) >> >> union can have as many case as possible. e.g., union(A,B,C,D,…) >> >> So the Optional<UITableView> should be union(UITableView, None) >> and Optional<MyTableVIew> should be union(MyTableView, None), which is >> subclass of union(UITableView, None) >> >> This is a final rational solution. I think. >> >> -Jiannan >> > > > > > _______________________________________________ > 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