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