[swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Xiaodi Wu]

I don't know if the core team feels differently now with respect to Swift
4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

Is there anything in your proposal that goes beyond previous discussions on
the topic?
On Wed, Aug 10, 2016 at 21:59 Cao, Jiannan via swift-evolution <
swift-evolution at swift.org> wrote:

> It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void
>
> Detail explain:
>
> var fn0: A->Void = {print($0)}
> var fn1: (A|B)->Void = {print(v0)}
> let a = A()
> let b = B()
>
> So:
>
> fn0( a ) // this is OK
> fn1( a ) // this is also OK
>
> fn1 is subtype of fn0, because fn1 can do anything fn0 do.
> Thus fn0 = fn1 is OK.
>
> But:
>
> fn1( b ) // this is OK
> fn0( b ) // this is not OK
>
> So fn0 is not subtype of fn1
>
> At 2016-08-11 10:41:02, "Step C" <schristopher at bignerdranch.com> wrote:
>
> Shouldn't it be "fn1 = fn0"? Same for the fn2 statements.
>
> `var fn0: A->Void = {print(v0)}
> var fn1: (A|B)->Void = {print(v0)}
>
>  fn0 = fn1 // OK, because Original Type and Union Type has a sub-typing
> relationship var
>
> fn2: (A|B|C)->Void = {print($0)}
>
>  fn0 = fn2 // OK
>  fn1 = fn2 // OK`
>
> On Aug 10, 2016, at 9:28 PM, Cao Jiannan via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi all,
>
> I want to make a discussion about union type for swift 4.
> See
> https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md
>
> Add union type grammar, represents the type which is one of other types.
>
> var stringOrURL: String | URL = "https://www.apple.com"
>
> Now, if we using the new union type feature, we can declare type
> conveniently, No other type declaration, and compiler will automatically
> calculate the common interface.
>
> func input(value: A | B | C) {
>     print(value.commonProperty) // type checker will calculate the common interface, developer just use it out of box
>     switch value {
>     case let value as A:
>         // value is type A
>         print(value.propertyInA)
>     case let value as B:
>         // value is type B
>         print(value.propertyInB)
>     case let value as C:
>         // value is type C
>         print(value.propertyInC)
>     }
>     // there is no default case other than A, B or C. we already declared that.
> }
>
> Note: A, B, C can be either class or protocol, or any other types. This
> leaves developer more freedom.
>
> Impact on existing code
>
>    - This is a new feature, developer who need declare common type will
>    alter to this new grammar.
>    - Enum based version optional or IUO will be replaced by Union-based
>    ones. Any optional type will automatically replaced by union type
>
>
>
> <https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md#detailed-design>
>
> _______________________________________________
> 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/20160811/61e32d46/attachment.html>