[swift-evolution] [Proposal] Union Type

[Matthew Johnson]

Sent from my iPad

> On Jul 1, 2016, at 1:59 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/ecd059e2/attachment.html>