Sent from my iPad
> On Jul 1, 2016, at 1:59 PM, David Sweeris via swift-evolution > <[email protected]> wrote: > > It’s already on that list. That’s what Joe was quoting from earlier. > > Everybody (I hope) understands the “something the type system cannot […] > support” part, but if the “should not” bit were expanded a bit so that people > would know why it shouldn’t be supported… I would also find elaboration of the rationale here very interesting (as well as the reason this "cannot" be supported by Swift's type systems while languages like Ceylon don't have a problem supporting it). I know the core team has very good reasons for their position on this but I don't have a clear understanding of what they are. I have run into use cases where unions would be the most elegant solution and currently possible solutions require boilerplate. This makes me wonder why the more elegant solution doesn't have a future in Swift. > > The closest I ever saw to a reason was a reply from back in the “Contiguous > Variables (A.K.A. Fixed Sized Array Type)” thread > (http://article.gmane.org/gmane.comp.lang.swift.evolution/6363) > >> Types aren't just bags of operations, which means that taking the >> intersection of arbitrary types isn't meaningful. Similarly, generics aren't >> templates to be instantiated, meaning that there has to be a run-time >> representation of a "value of intersection type". >> >> The constructs that carries the right meaning in Swift are protocols, and in >> theory you could intersect the protocols of the various types. In practice, >> though, the current model doesn't have a good way to actually do this, since >> not all protocols can be used as types of values, and finding the >> protocol-intersection of N types is a needless amount of extra work for the >> compiler anyway. Thanks for digging this up. It's interesting to note that the use cases I have run into don't rely on exposing intersecting operations, only the ability to store a value of one of n types and switch to uncover the underlying value. I wonder if the rationale for avoiding unions is strictly related to discovering and exposing the intersecting operations of the types. Maybe a weaker kind of union that doesn't expose any operations other than casting and pattern matching would be more acceptable. I agree with the statement that protocols should be used when the goal is to abstract over common operations. > > Which, at least to me, isn’t very convincing. In the author’s defense, I > don’t think the post was intended to be a rigorous rebuttal of the idea. > > - Dave Sweeris > >> On Jul 1, 2016, at 12:47 PM, L. Mihalkovic via swift-evolution >> <[email protected]> wrote: >> >> @core team: should the be added to the list of common rejections for now or >> does it stand a chance in the next 2 or 3 versions? >> >> Regards >> LM >> (From mobile) >> >>> On Jul 1, 2016, at 11:06 AM, Cao Jiannan via swift-evolution >>> <[email protected]> wrote: >>> >>> https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md >>> >>> Hi, >>> >>> I'm now officially proposal the union type feature for Swift. Please see: >>> >>> >>> https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121 >>> Introduction >>> >>> Add union type grammar, represents the type which is one of other types. >>> >>> var stringOrURL: String | URL = "https://www.apple.com"; >>> >>> >>> I would be thankful if someone support this idea and give some advice. >>> Thanks! >>> >>> >>> -- >>> Jiannan >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
