On May 17, 2016, at 6:09 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
Jiannan, I agree there is an use for union types, I'm just not really fond of the syntax (I'd really prefer something like 'union<...>') and with using it for optionals. To enable this syntax for optionals, None would have to be a valid type of the language and that would enable one to create the following constructions:
func something(value: None) -> None { ... }
It wouldn't be essentially wrong but unnecessary since nil would be the only possible value of the type None. And I don't really see any need to change the way optionals are implemented to support unions. And we could still have optional unions using either syntax with existing optional syntax (which is very clear to me):
func something(value: (A | B | C)?) { ... }
or
func something(value: union<A, B, C>?) { ... }
Just as I said before, I don't really think unions are necessary (did you mean overloading?) but I don't oppose them. I just don't think we need to change the way a feature already works to justify the addition of a new feature.
- Leonardo
On 16 May 2016 at 08:26, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:
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@haravikk.me>
主题: 回复： [swift-evolution] Union instead of Optional
日期: 2016年5月16日 GMT+8 18:35:25
收件人: Austin Zheng <austinzheng@gmail.com>
抄送: Cao Jiannan <frogcjn@163.com>, Adrian Zubarev via swift-evolution <swift-evolution@swift.org>
On 16 May 2016, at 11:17, Austin Zheng via swift-evolution <swift-evolution@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?
_______________________________________________
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