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...@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@swift.org <mailto:swift-evolution@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" <schristop...@bignerdranch.com
> <mailto:schristop...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
