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

[Charlie Monroe]

Seeing from the sample codes, this is just a syntax for anonymous enums, which were discussed here a few months ago. I personally don't see that much advantage in it given it is more restrictive than an enum (you can't have two cases with the same payload type) and it leads to people retyping these anonymous enums rather than declaring a type - which in general leads to a less readable language - when do I pass in type A, when type B, when type C? Enum has those cases named.

Would this be valid?

let x: A | B = y
func input(value: A | B | C) {}

input(value: x)

I.e. supplying a union of fewer types into a union of superset of the types?

> On Aug 11, 2016, at 5:55 AM, Cao Jiannan via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto: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>
> 
> _______________________________________________
> 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/b1e3ef4a/attachment.html>