Union is far better then generic enum/protocol solution.
* It can extend the original enum and make it powerful.
enum ResultDataType {
case Music
case Video
case File
}
enum FailureType {
case HTTP404
case HTTP502
}
enum FailureTypev2 {
case HTTP451
}
typealias Result = (ResultDataType | FailureType | FailureTypev2)
* It keeps the code clear and does not need developer to announce some
unnecessary protocols or enums.
like UnionOf3<T,U,V> or ProtocolForABC
* It is easy to wrap original value into an union type.
let a = A()
let union: (A|B|C) = a // Automatically wrap.
* Compiler might search their common properties, and methods, then mark
them as a member of the union type.
print(value.someCommonProperty) // Compiler will know their
common properties automatically.
* Compiler know the union type exactly composed with which types,
better than only know which protocol.
func input(value: ProtocolForABC) {
if value is A {
} else if value is B {
} else if value is C {
} else {
// There are other cases? Compiler doesn't know
}
}
* Original types and union types can have a rational relationship
between each other.
Original type is a sub-type of union types contain it.
var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}
fn0 = fn1 // Original Type and Union Type has a sub-typing
relationship, OK
var fn2: (A|B|C)->Void = {print($0)}
fn0 = fn2 // OK
fn1 = fn2 // OK
* It is also easy to compare with value of original type.
union == a // Can be compared, Yes for most cases.
* And the most important part, It can replace Optional<T>.
let string: String?
is same to
let string: (String | None) instead of let string:
Optional<String>
I really think the union type is a good supplement for Swift. Make the language
rational.
And the It is also really good for Reactive Programming.
- Jiannan
> 下面是被转发的邮件：
>
> 发件人: Haravikk <[email protected]>
> 主题: 回复： [swift-evolution] Union instead of Optional
> 日期: 2016年5月16日 GMT+8 18:35:25
> 收件人: Austin Zheng <[email protected]>
> 抄送: Cao Jiannan <[email protected]>, Adrian Zubarev via swift-evolution
> <[email protected]>
>
>
>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution
>> <[email protected]> wrote:
>>
>> If A, B, and C are not related via protocol or class inheritance, then there
>> is almost nothing you can do with value. Otherwise you still need to test
>> against the concrete type using a case statement or a if-else ladder.
>
> I think that a case statement or similar syntax will still be needed, and the
> case names would just be the types themselves. This would work best with
> support for type-narrowing, for example:
>
> func someMethod(value:(A|B|C)) {
> switch (value) {
> case .A:
> value.someMethodForTypeA()
> case .B:
> value.someMethodForTypeB()
> case .C:
> value.someMethodForTypeC()
> }
> }
>
> A union should really just be though of as a lightweight, restricted form of
> enum that can be declared in a quick ad-hoc fashion, similar to how tuples
> are a simpler form of struct.
>
> I’m generally a +1 for the feature, but I’d be interested to hear about how
> well equipped the compiler is for optimising something like this. In most
> cases an Optional covers what I need, and in more complex cases I’d probably
> declare overloads for each type (i.e- someMethod(value:A),
> someMethod(value:B) etc.); unions could make the latter case simpler, but
> will the compiler produce the same code behind the scenes, i.e- by isolating
> what’s unique to each type?
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
