FYI, this is clearly out of scope for Swift 3. Please wait until Swift 3 is wound down before bringing this up. Also beware that this topic has come up several times before and there are major semantic problems with it. Please familiarize yourself with those previous discussions.
-Chris
···
On Jul 1, 2016, at 2:06 AM, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:
Disjunctions (logical ORs) in type constraints <https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000182.html>: These include anonymous union-like types (e.g. (Int | String) for a type that can be inhabited by either an integer or a string). "[This type of constraint is] something that the type system cannot and should not support."
-Joe
···
On Jul 1, 2016, at 2:08 AM, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:
Hi all,
I'm now officially proposal the union type feature for Swift. Please see:
It’s already on that list. That’s what Joe was quoting from earlier.
Everybody (I hope) understands the “something the type system cannot […] support” part, but if the “should not” bit were expanded a bit so that people would know why it shouldn’t be supported…
Types aren't just bags of operations, which means that taking the intersection of arbitrary types isn't meaningful. Similarly, generics aren't templates to be instantiated, meaning that there has to be a run-time representation of a "value of intersection type".
The constructs that carries the right meaning in Swift are protocols, and in theory you could intersect the protocols of the various types. In practice, though, the current model doesn't have a good way to actually do this, since not all protocols can be used as types of values, and finding the protocol-intersection of N types is a needless amount of extra work for the compiler anyway.
Which, at least to me, isn’t very convincing. In the author’s defense, I don’t think the post was intended to be a rigorous rebuttal of the idea.
- Dave Sweeris
···
On Jul 1, 2016, at 12:47 PM, L. Mihalkovic via swift-evolution <swift-evolution@swift.org> wrote:
@core team: should the be added to the list of common rejections for now or does it stand a chance in the next 2 or 3 versions?
Regards
LM
(From mobile)
On Jul 1, 2016, at 11:06 AM, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
It’s already on that list. That’s what Joe was quoting from earlier.
Everybody (I hope) understands the “something the type system cannot […] support” part, but if the “should not” bit were expanded a bit so that people would know why it shouldn’t be supported…
I would also find elaboration of the rationale here very interesting (as well as the reason this "cannot" be supported by Swift's type systems while languages like Ceylon don't have a problem supporting it). I know the core team has very good reasons for their position on this but I don't have a clear understanding of what they are.
I have run into use cases where unions would be the most elegant solution and currently possible solutions require boilerplate. This makes me wonder why the more elegant solution doesn't have a future in Swift.
Types aren't just bags of operations, which means that taking the intersection of arbitrary types isn't meaningful. Similarly, generics aren't templates to be instantiated, meaning that there has to be a run-time representation of a "value of intersection type".
The constructs that carries the right meaning in Swift are protocols, and in theory you could intersect the protocols of the various types. In practice, though, the current model doesn't have a good way to actually do this, since not all protocols can be used as types of values, and finding the protocol-intersection of N types is a needless amount of extra work for the compiler anyway.
Thanks for digging this up. It's interesting to note that the use cases I have run into don't rely on exposing intersecting operations, only the ability to store a value of one of n types and switch to uncover the underlying value. I wonder if the rationale for avoiding unions is strictly related to discovering and exposing the intersecting operations of the types. Maybe a weaker kind of union that doesn't expose any operations other than casting and pattern matching would be more acceptable.
I agree with the statement that protocols should be used when the goal is to abstract over common operations.
···
Sent from my iPad
On Jul 1, 2016, at 1:59 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:
Which, at least to me, isn’t very convincing. In the author’s defense, I don’t think the post was intended to be a rigorous rebuttal of the idea.
- Dave Sweeris
On Jul 1, 2016, at 12:47 PM, L. Mihalkovic via swift-evolution <swift-evolution@swift.org> wrote:
@core team: should the be added to the list of common rejections for now or does it stand a chance in the next 2 or 3 versions?
Regards
LM
(From mobile)
On Jul 1, 2016, at 11:06 AM, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:
// Copy and merge types into the new `OneOf` type
return OneOf<...T, ...U>
}
Your example will become:
typealias ABC = A | B | C // or OneOf<A, B, C>
typealias ABCD = ABC | D // merging lhs OneOf with D to OneOf<A, B, C, D>
Mission accomplished.
Again this is not a true union type because String | String != String
You’d get a OneOf enum with both first and second case as A. You still can distinguish them by the indexed label.
let test = OneOf<A, A>.init(index: 0, value: A())
switch test {
case .$1(let value)
// do something
case .$2(let value)
// do something
}
Again this is all bikeshedding of variadic generics and variadic enums!
···
--
Adrian Zubarev
Sent with Airmail
Am 1. Juli 2016 um 11:08:40, Cao Jiannan via swift-evolution (swift-evolution@swift.org) schrieb:
Hi all,
I'm now officially proposal the union type feature for Swift. Please see:
Introduction
Add union type grammar, represents the type which is one of other types.
T_T I’ve never said it will compile (the second time now), I’ve said couple of times its just future bikeshedding with variadic generics from the generics manifesto and variadic enum cases that I come up with.
···
--
Adrian Zubarev
Sent with Airmail
Am 1. Juli 2016 um 15:33:41, Cao Jiannan via swift-evolution (swift-evolution@swift.org) schrieb:
I can't compile your code. I'm really not sure your code will pass the complex generic check
Union version more complex or generic version?
I think union version is more normal.
For example:
typealias ABC = A | B | C
typealias ABCD = ABC | D
we just use an existed type ABC to construct ABCD
But how about generic wrap?
Bikeshedding:
// we generate the boundary with `A | B` or directly OneOf<A, B>
enum OneOf<...T> {
...case $#(T)
// Bikeshedding variadic enum casses:
// we might need an index to set the value?
init(index: Int, value: T) {
self = .$index(value)
}
}
/// Usage:
/// A | B | C == OneOf<A, B, C>
func |<T, U>(_: T.Type, _: U.Type) -> OneOf<T, U>.Type {
// I believe the usage of `type` like this was prposed by Joe Groff
// I also use the proposal to remove `.self` magic here
return OneOf<T, U>
}
// Here is how to merge OneOf into a single dimension
func |<...T, U>(_: OneOf<...T>.Type, _: U.Type) -> OneOf<...T, U>.Type {
// Copy and merge types into the new `OneOf` type
return OneOf<...T, U>
}
But in the union type design, String == String | String, this is always true
I already answered that question:
For example:
typealias ABC = A | B | C
typealias ABCD = ABC | D
we just use an existed type ABC to construct ABCD
But how about generic wrap?
Bikeshedding:
// we generate the boundary with `A | B` or directly OneOf<A, B> enum OneOf<...T> { ...case $#(T) // Bikeshedding variadic enum casses: // we might need an index to set the value? init(index: Int, value: T) { self = .$index(value) } } /// Usage: /// A | B | C == OneOf<A, B, C> func |<T, U>(_: T.Type, _: U.Type) -> OneOf<T, U>.Type { // I also use the proposal to remove `.self` magic here return OneOf<T, U> } // Here is how to merge OneOf into a single dimension func |<...T, U>(_: OneOf<...T>.Type, _: U.Type) -> OneOf<...T, U>.Type { // Copy and merge types into the new `OneOf` type return OneOf<...T, U> } func |<T, ...U>(_: T.Type, _: OneOf<...U>.Type) -> OneOf<T, ...U>.Type { // Copy and merge types into the new `OneOf` type return OneOf<T, ...U> } func |<...T, ...U>(_: OneOf<...T>.Type, _: OneOf<...U>.Type) -> OneOf<...T, ...U>.Type { // Copy and merge types into the new `OneOf` type return OneOf<...T, ...U> }
Your example will become:
typealias ABC = A | B | C // or OneOf<A, B, C> typealias ABCD = ABC | D // merging lhs OneOf with D to OneOf<A, B, C, D>
Mission accomplished.
Again this is not a true union type because String | String != String
You’d get a OneOf enum with both first and second case as A. You still can distinguish them by the indexed label.
let test = OneOf<A, A>.init(index: 0, value: A()) switch test { case .$1(let value) // do something case .$2(let value) // do something }
Again this is all bikeshedding of variadic generics and variadic enums!
My proposal begins on February, still in May. But may no make attention to you.
This proposal is more about how to change the way of thinking optional/either type. Change the way of using generic to construct optional/either type.
···
下面是被转发的邮件:
发件人: Joe Groff <jgroff@apple.com>
主题: 回复: [swift-evolution] [Proposal] Union Type
日期: 2016年7月2日 GMT+8 01:03:17
收件人: Cao Jiannan <frogcjn@163.com>
抄送: swift-evolution <swift-evolution@swift.org>
On Jul 1, 2016, at 2:08 AM, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,
I'm now officially proposal the union type feature for Swift. Please see:
Disjunctions (logical ORs) in type constraints <https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000182.html>: These include anonymous union-like types (e.g. (Int | String) for a type that can be inhabited by either an integer or a string). "[This type of constraint is] something that the type system cannot and should not support."