[swift-evolution] [proposal] Union Type

[Leonardo Pessoa]

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 at 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-evolution at haravikk.me>
> *主题: **回复： [swift-evolution] Union instead of Optional*
> *日期: *2016年5月16日 GMT+8 18:35:25
> *收件人: *Austin Zheng <austinzheng at gmail.com>
> *抄送: *Cao Jiannan <frogcjn at 163.com>, Adrian Zubarev via swift-evolution <
> swift-evolution at swift.org>
>
>
> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution <
> swift-evolution at 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 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/20160517/ea1d5fd4/attachment-0001.html>