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.

funcinput(value: A | B | C) {
print(value.commonProperty) // type checker will calculate the common interface, developer just use it out of boxswitch value {
caselet value as A:
// value is type Aprint(value.propertyInA)
caselet value as B:
// value is type Bprint(value.propertyInB)
caselet value as C:
// value is type Cprint(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

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

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 <mailto:swift-evolution@swift.org>> wrote:
It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void

Add union type grammar, represents the type which is one of other types.

var stringOrURL: String | URL = "https://www.apple.com <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

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 <mailto:swift-evolution@swift.org>> wrote:
It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void

Add union type grammar, represents the type which is one of other types.

var stringOrURL: String | URL = "https://www.apple.com <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

Swift is not Typescript, and this topic has been discussed extensively in the past. We expect you to familiarize yourself with those discussions. Otherwise, it is just a waste of people’s time to rehash old arguments.

While I appreciate if you don’t want to reply, given the way the tone of this discussion seems to have turned:

The section on this topic in the “commonly-proposed” section could use some elaborating. On the face of it, it seems like a handy feature, and I’m sure many would like to know (now and in the future) why the core-team feels this way. Only then can they properly judge when circumstances may have changed, and if/when to raise the issue again.

Add union type grammar, represents the type which is one of other types.

var stringOrURL: String | URL = "https://www.apple.com <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

Seeing from the sample codes, this is just a syntax for anonymous enums, which were discussed here a few months ago. I personally don't see that much advantage in it given it is more restrictive than an enum (you can't have two cases with the same payload type) and it leads to people retyping these anonymous enums rather than declaring a type - which in general leads to a less readable language - when do I pass in type A, when type B, when type C? Enum has those cases named.

Would this be valid?

let x: A | B = y
func input(value: A | B | C) {}

input(value: x)

I.e. supplying a union of fewer types into a union of superset of the types?

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 <mailto:swift-evolution@swift.org>> wrote:
It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void

Add union type grammar, represents the type which is one of other types.

var stringOrURL: String | URL = "https://www.apple.com <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

Swift is not Typescript, and this topic has been discussed extensively in
the past. We expect you to familiarize yourself with those discussions.
Otherwise, it is just a waste of people’s time to rehash old arguments.

Some ones proposal have always been accepted very quickly even though it is not fully discussed.

I don't know why.

so if some one always focus on swift-evolution then it has more priority to proposal?

What about others?

I proposal this since February, May. no one said it is a problem. But in June, some one lead an idea of & and union type proposal has been listed in not-welcomed proposal for Swift 3. No one notify me that discussion and no one discussed that with me. I try to discuss with the core team but they have no response before June. But After June, they said it is not for Swift 3. OK, I proposed for Swift 4, and get a shit response.

Email list let proposal topic hide themselves?

No direct answer of my Feb, May proposal, but a June discussed sometime somewhere I don't know.

Swift is not Typescript, and this topic has been discussed extensively in the past. We expect you to familiarize yourself with those discussions. Otherwise, it is just a waste of people’s time to rehash old arguments.

"FWIW, this has been discussed before on swift-evolution. Adding them
isn’t out of the question, but it is a lot more complicated than it looks
for the type checker."

"Here is my concern: Swift enums should be good enough that we don’t need
an Either type. If defining your own custom enum is hard or bad, then we
should fix that.

There are a number of concepts floating around that would make enums better
in various ways. One specific one would be to synthesize optional
accessors that line up with enum cases."
- in "Either in the Swift Standard Library"

While I appreciate if you don’t want to reply, given the way the tone of
this discussion seems to have turned:

The section on this topic in the “commonly-proposed” section could use
some elaborating. On the face of it, it seems like a handy feature, and I’m
sure many would like to know (now and in the future) why the core-team
feels this way. Only then can they properly judge when circumstances may
have changed, and if/when to raise the issue again.

Considering "&" for types is already decided, symmetry would be enough motivation for me to add "|" as well.

Maybe I would even support replacing enums with associated values in favor of union types (my impression is that enums aren't as useful as I thought when I started using them).

But right now, this doesn't seem to be a time for discussing huge changes, but for actually implementing smaller ones
I'm a little bit concerned that Swift might already be preferring compatibility over elegance, but the defensive attitude that you perceived might as well be explained with release-stress…

Of course, rejection is still frustrating — but please consider that most proposals aren't accompanied by an implementation, so every wish that's accepted adds something to the pile of work to be done by the core team.
Imho it would be nice if Swift evolution would be more "decentralized", moving away from proposals like "I want to have feature X" towards "I want to develop feature X, is there a chance this could be integrated?", but coordination is already hard enough, so this might be unfeasible.

Some ones proposal have always been accepted very quickly even though it is not fully discussed.

I don't know why.

so if some one always focus on swift-evolution then it has more priority to proposal?

What about others?

I proposal this since February, May. no one said it is a problem. But in June, some one lead an idea of & and union type proposal has been listed in not-welcomed proposal for Swift 3. No one notify me that discussion and no one discussed that with me. I try to discuss with the core team but they have no response before June. But After June, they said it is not for Swift 3. OK, I proposed for Swift 4, and get a shit response.

Email list let proposal topic hide themselves?

No direct answer of my Feb, May proposal, but a June discussed sometime somewhere I don't know.

so I make a proposal, and this is the result.

In parts I can understand your frustration although your kind of reaction cuts everybody’s slack, because it is well behind rules of politeness/netiquette whatever. I think it is „normal“ that more active members that have provided good input already get automatically some bonus, even if it was not intended. Its just human.

I am quite new here and tried to add some value to discussions where I have confidence and I had the slight feeling that sometimes people that are more involved in the evolution process take a quick, vague look at my text and answer with some very generic and devastating commentary. This can be frustrating, but still it is a normal thing.

In Kotlin’s evolution process they use different media for different stadium of discussion (which has been proposed here too) and for each stadium they start to introduce a given process (the procedure is work in progress). Currently, there it is like this:

* discuss on Slack to get a feeling whether community gives some response (nobody expects that you look back for months in that history)
* create an issue in their issue tracker for further discussions
* if you get a *go* from the core team create a proposal (with a very similar format as the proposals have here) and create a pull request
* after some discussion you may either abandon your proposal or try to get a so called „shepherd“ from the core team
* from now on the shepherd guides the discussion

I didn’t get further than this yet, so I don’t know whether they have a community voting procedure, but it would be a nice addition.

Perhaps such a more guided (and comprehensible) procedure would help to keep track and make the process more fair (since the goal is to make swift better not to support personal self-affirmation like e.g. the german wikipedia administrators do).

Swift is not Typescript, and this topic has been discussed extensively in the past. We expect you to familiarize yourself with those discussions. Otherwise, it is just a waste of people’s time to rehash old arguments.

Considering "&" for types is already decided, symmetry would be enough
motivation for me to add "|" as well.

Tino, this line of reasoning was explicitly addressed by the core team when
they approved "&". In fact, it was their "princip[al] concern" about "&":

"The principle concern with this is that having an “&" operator for generic
constraints leads the question of whether the language should introduce an
"|" operator to represent disjunctions in type constraints (something that
the type system cannot and should not support). This is a topic that the
C++ committee grappled with in its discussions of C++ concepts. That said,
the core team feels that “&” directly expresses the relationship that we
want, that “|” can be addressed in the “commonly rejected proposals" list,
and that other proposals for an infix operator (like +) skirt this issue
but are strictly worse at communicating intent in code."

Maybe I would even support replacing enums with associated values in favor
of union types (my impression is that enums aren't as useful as I thought
when I started using them).

But right now, this doesn't seem to be a time for discussing huge changes,
but for actually implementing smaller ones
I'm a little bit concerned that Swift might already be preferring
compatibility over elegance, but the defensive attitude that you perceived
might as well be explained with release-stress…

Of course, rejection is still frustrating — but please consider that most
proposals aren't accompanied by an implementation, so every wish that's
accepted adds something to the pile of work to be done by the core team.
Imho it would be nice if Swift evolution would be more "decentralized",
moving away from proposals like "I want to have feature X" towards "I want
to develop feature X, is there a chance this could be integrated?", but
coordination is already hard enough, so this might be unfeasible.