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

[Thorsten Seitz]

> Am 11.08.2016 um 04:58 schrieb Cao, Jiannan via swift-evolution <swift-evolution at swift.org>:
> 
> It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void 

That is correct as (A|B) is a supertype of A and it occurs in a contravariant position (argument position) of the funcion type, so (A|B) -> Void is a subtype of A -> Void.

The current version of the proposal (https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md#detailed-design) seems to have been changed, though, as it has it the other way round (i.e. fn1 = fn0).

-Thorsten

> 
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160911/d144b8bd/attachment.html>