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

[Cao Jiannan]

Union type is powerful. It can make up optional, let it leaves terrible generic wrap.

And the most important part, It can replace enum Optional<T> to represent optional types.
    let string: String?
is same to

    let string: String | None
instead of

    let string: Optional<String>
IUO, Implicity Unwrapped Optional, can also use union to represent
    let string: String!
will be the same as the union grammar:

    let iuo: *String | None

> 在 2016年8月11日，11:15，Xiaodi Wu <xiaodi.wu at gmail.com> 写道：
> 
> 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 <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 <mailto: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 <mailto: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 <mailto: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 <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 <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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
>  
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/582030c1/attachment.html>