[swift-evolution] [proposal] Union Type

[Cao Jiannan]

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 <swift-evolution at haravikk.me>
> 主题: 回复： [swift-evolution] Union instead of Optional
> 日期: 2016年5月16日 GMT+8 18:35:25
> 收件人: Austin Zheng <austinzheng at gmail.com>
> 抄送: Cao Jiannan <frogcjn at 163.com>, Adrian Zubarev via swift-evolution <swift-evolution at swift.org>
> 
> 
>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution <swift-evolution at swift.org> 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?

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