[Pre-Proposal-Discussion] Union Type - Swift 4

frogcjn · 2016-08-11T02:58:58.000Z

It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void

Detail explain:

var fn0: A->Void = {print($0)}
var fn1: (A|B)->Void = {print(v0)}
let a = A()
let b = B()

So:

fn0( a ) // this is OK
fn1( a ) // this is also OK

fn1 is subtype of fn0, because fn1 can do anything fn0 do.
Thus fn0 = fn1 is OK.

But:

fn1( b ) // this is OK
fn0( b ) // this is not OK

So fn0 is not subtype of fn1

···

At 2016-08-11 10:41:02, "Step C" <schristopher@bignerdranch.com> wrote:

Shouldn't it be "fn1 = fn0"? Same for the fn2 statements.

`var fn0: A->Void= {print(v0)}
var fn1: (A|B)->Void= {print(v0)}

fn0 = fn1 // OK, because Original Type and Union Type has a sub-typing relationshipvar

fn2: (A|B|C)->Void= {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK`

On Aug 10, 2016, at 9:28 PM, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I want to make a discussion about union type for swift 4.
See swift-evolution/xxxx-union-type.md at master · frogcjn/swift-evolution · GitHub

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

var stringOrURL: String| URL ="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.

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Chris_Lattner · 2016-08-11T05:18:54.000Z

There is no change in opinion here. This topic is also out of scope for Swift 4 stage 1 in any case.

-Chris

···

On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

xwu · 2016-08-11T03:15:37.000Z

I don't know if the core team feels differently now with respect to Swift
4, but union types are listed as a "commonly rejected change":

github.com

apple/swift-evolution/blob/main/commonly_proposed.md

# Commonly Rejected Changes 

This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted.  If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had.  In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".

Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [dashboard](https://www.swift.org/swift-evolution/) includes a list of changes that have been rejected after a formal review.

Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and Javascript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).

## Basic Syntax and Operators

 * [Replace `{}` brace syntax with Python-style indentation](https://forums.swift.org/t/brace-syntax/678/3): Surely a polarizing issue, but Swift will not change to use indentation for scoping instead of curly braces.

 * [Remove `;` semicolons](https://forums.swift.org/t/proposal-to-remove-semicolons/523/3): Semicolons within a line are an intentional expressivity feature.  Semicolons at the end of the line should be handled by a linter, not by the compiler.

 * [Replace logical operators (`&&`, `||`, `!`, etc.) with words like "and", "or", "not"](https://forums.swift.org/t/change-the-name-of-the-boolean-operators/30/2), and [allow non-punctuation operators](https://forums.swift.org/t/allowing-characters-for-use-as-custom-operators/952) and infix functions: The operator and identifier grammars are intentionally partitioned in Swift, which is a key part of how user-defined overloaded operators are supported.  Requiring the compiler to see the "operator" declaration to know how to parse a file would break the ability to be able to parse a Swift file without parsing all of its imports.  This has a major negative effect on tooling support. While not needing infix support, `not` would need operator or keyword status to omit the parentheses as `!` can, and `not somePredicate()` visually binds too loosely compared to `!somePredicate()`.

 * [Replace `?:` ternary operator](https://forums.swift.org/t/ternary-operator-suggestion/49/148): Definitely magical, but it serves a very important use-case for terse selection of different values.  Proposals for alternatives have been intensely discussed, but none have been "better enough" for it to make sense to diverge from the precedent established by the C family of languages.

## Strings, Characters, and Collection Types

This file has been truncated. show original

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> wrote:

It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void

Detail explain:

var fn0: A->Void = {print($0)}
var fn1: (A|B)->Void = {print(v0)}
let a = A()
let b = B()

So:

fn0( a ) // this is OK
fn1( a ) // this is also OK

fn1 is subtype of fn0, because fn1 can do anything fn0 do.
Thus fn0 = fn1 is OK.

But:

fn1( b ) // this is OK
fn0( b ) // this is not OK

So fn0 is not subtype of fn1

At 2016-08-11 10:41:02, "Step C" <schristopher@bignerdranch.com> wrote:

Shouldn't it be "fn1 = fn0"? Same for the fn2 statements.

`var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}

fn0 = fn1 // OK, because Original Type and Union Type has a sub-typing
relationship var

fn2: (A|B|C)->Void = {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK`

On Aug 10, 2016, at 9:28 PM, Cao Jiannan via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

I want to make a discussion about union type for swift 4.
See
https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md

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

var stringOrURL: String | URL = "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

<https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md#detailed-design>

_______________________________________________
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

frogcjn · 2016-08-11T03:52:03.000Z

https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000182.html
you can go for detail. it is for Swift 3.

and swift-evolution should be open mind. Since it ask us to make proposals.

···

在 2016年8月11日，11:15，Xiaodi Wu <xiaodi.wu@gmail.com> 写道：

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

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

Detail explain:

var fn0: A->Void = {print($0)}
var fn1: (A|B)->Void = {print(v0)}
let a = A()
let b = B()

So:

fn0( a ) // this is OK
fn1( a ) // this is also OK

fn1 is subtype of fn0, because fn1 can do anything fn0 do.
Thus fn0 = fn1 is OK.

But:

fn1( b ) // this is OK
fn0( b ) // this is not OK

So fn0 is not subtype of fn1

At 2016-08-11 10:41:02, "Step C" <schristopher@bignerdranch.com <mailto:schristopher@bignerdranch.com>> wrote:
Shouldn't it be "fn1 = fn0"? Same for the fn2 statements.

`var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}

fn0 = fn1 // OK, because Original Type and Union Type has a sub-typing relationship var

fn2: (A|B|C)->Void = {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK`

On Aug 10, 2016, at 9:28 PM, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I want to make a discussion about union type for swift 4.
See https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md

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

<https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md#detailed-design>\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

frogcjn · 2016-08-11T03:55:08.000Z

Union type is powerful. It can make up optional, let it leaves terrible generic wrap.

And the most important part, It can replace enum Optional<T> to represent optional types.
let string: String?
is same to

let string: String | None
instead of

let string: Optional<String>
IUO, Implicity Unwrapped Optional, can also use union to represent
let string: String!
will be the same as the union grammar:

let iuo: *String | None

···

在 2016年8月11日，11:15，Xiaodi Wu <xiaodi.wu@gmail.com> 写道：

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

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

Detail explain:

var fn0: A->Void = {print($0)}
var fn1: (A|B)->Void = {print(v0)}
let a = A()
let b = B()

So:

fn0( a ) // this is OK
fn1( a ) // this is also OK

fn1 is subtype of fn0, because fn1 can do anything fn0 do.
Thus fn0 = fn1 is OK.

But:

fn1( b ) // this is OK
fn0( b ) // this is not OK

So fn0 is not subtype of fn1

At 2016-08-11 10:41:02, "Step C" <schristopher@bignerdranch.com <mailto:schristopher@bignerdranch.com>> wrote:
Shouldn't it be "fn1 = fn0"? Same for the fn2 statements.

`var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}

fn0 = fn1 // OK, because Original Type and Union Type has a sub-typing relationship var

fn2: (A|B|C)->Void = {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK`

On Aug 10, 2016, at 9:28 PM, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I want to make a discussion about union type for swift 4.
See https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md

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

<https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md#detailed-design>\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

frogcjn · 2016-08-11T05:25:01.000Z

Swift evolution seems not an evolution.

I'll leave this mail list since this is not a good proposal environment.
Typescript and other language community is more open to new idea. Swift-evolution is just a weird community.

You just accept what you like and what you want. Is this called swift-evolution or proposal?

Proposal is for a long time standard, not just for next version of your shame release.

在 2016-08-11 13:18:54，"Chris Lattner" <clattner@apple.com> 写道：

···

On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

github.com

apple/swift-evolution/blob/master/commonly_proposed.md

# Commonly Rejected Changes 
 
This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted.  If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had.  In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".

Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [proposal review status page](https://apple.github.io/swift-evolution/) includes a list of changes that have been deferred for future discussion because they were deemed to be out of scope at the time of review (in addition to a list of changes proposed and rejected after a formal review).

Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and Javascript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).

## Basic Syntax and Operators

 * [Replace `{}` brace syntax with Python-style indentation](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html): Surely a polarizing issue, but Swift will not change to use indentation for scoping instead of curly braces.
 
 * [Remove `;` semicolons](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002421.html): Semicolons within a line are an intentional expressivity feature.  Semicolons at the end of the line should be handled by a linter, not by the compiler.

 * [Replace logical operators (`&&`, `||`, `!`, etc.) with words like "and", "or", "not"](https://lists.swift.org/pipermail/swift-evolution/2015-December/000032.html), and [allow non-punctuation operators](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005669.html) and infix functions: The operator and identifier grammars are intentionally partitioned in Swift, which is a key part of how user-defined overloaded operators are supported.  Requiring the compiler to see the "operator" declaration to know how to parse a file would break the ability to be able to parse a Swift file without parsing all of its imports.  This has a major negative effect on tooling support. While not needing infix support, `not` would need operator or keyword status to omit the parentheses as `!` can, and `not somePredicate()` visually binds too loosely compared to `!somePredicate()`.

 * [Replace `?:` ternary operator](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002609.html): Definitely magical, but it serves a very important use-case for terse selection of different values.  Proposals for alternatives have been intensely discussed, but none have been "better enough" for it to make sense to diverge from the precedent established by the C family of languages.

## Strings, Characters, and Collection Types

This file has been truncated. show original

There is no change in opinion here. This topic is also out of scope for Swift 4 stage 1 in any case.

-Chris

frogcjn · 2016-08-11T05:53:39.000Z

OK. I'll shut up since I waste your time.

···

At 2016-08-11 13:41:59, "Chris Lattner" <clattner@apple.com> wrote:
You’re certainly welcome to your opinion.

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.

-Chris

On Aug 10, 2016, at 10:22 PM, Cao, Jiannan <frogcjn@163.com> wrote:

Swift evolution seems not an evolution.

I'll leave this mail list since this is not a good proposal environment. Typescript and other language community is more open to new idea. Swift-evolution is just a weird community.

在 2016-08-11 13:18:54，"Chris Lattner" <clattner@apple.com> 写道：

On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

github.com

apple/swift-evolution/blob/master/commonly_proposed.md

# Commonly Rejected Changes 
 
This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted.  If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had.  In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".

Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [proposal review status page](https://apple.github.io/swift-evolution/) includes a list of changes that have been deferred for future discussion because they were deemed to be out of scope at the time of review (in addition to a list of changes proposed and rejected after a formal review).

Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and Javascript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).

## Basic Syntax and Operators

 * [Replace `{}` brace syntax with Python-style indentation](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html): Surely a polarizing issue, but Swift will not change to use indentation for scoping instead of curly braces.
 
 * [Remove `;` semicolons](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002421.html): Semicolons within a line are an intentional expressivity feature.  Semicolons at the end of the line should be handled by a linter, not by the compiler.

 * [Replace logical operators (`&&`, `||`, `!`, etc.) with words like "and", "or", "not"](https://lists.swift.org/pipermail/swift-evolution/2015-December/000032.html), and [allow non-punctuation operators](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005669.html) and infix functions: The operator and identifier grammars are intentionally partitioned in Swift, which is a key part of how user-defined overloaded operators are supported.  Requiring the compiler to see the "operator" declaration to know how to parse a file would break the ability to be able to parse a Swift file without parsing all of its imports.  This has a major negative effect on tooling support. While not needing infix support, `not` would need operator or keyword status to omit the parentheses as `!` can, and `not somePredicate()` visually binds too loosely compared to `!somePredicate()`.

 * [Replace `?:` ternary operator](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002609.html): Definitely magical, but it serves a very important use-case for terse selection of different values.  Proposals for alternatives have been intensely discussed, but none have been "better enough" for it to make sense to diverge from the precedent established by the C family of languages.

## Strings, Characters, and Collection Types

This file has been truncated. show original

There is no change in opinion here. This topic is also out of scope for Swift 4 stage 1 in any case.

-Chris

Karl · 2016-08-17T23:06:49.000Z

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.

Thanks

Karl

···

On 11 Aug 2016, at 07:18, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

There is no change in opinion here. This topic is also out of scope for Swift 4 stage 1 in any case.

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

trs · 2016-09-11T11:11:04.000Z

It is no a mistake. since fn1: (A|B)->Void is subtype of fn0: A->Void

That is correct as (A|B) is a supertype of A and it occurs in a contravariant position (argument position) of the funcion type, so (A|B) -> Void is a subtype of A -> Void.

The current version of the proposal (https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md#detailed-design\) seems to have been changed, though, as it has it the other way round (i.e. fn1 = fn0).

-Thorsten

···

Am 11.08.2016 um 04:58 schrieb Cao, Jiannan via swift-evolution <swift-evolution@swift.org>:

Detail explain:

var fn0: A->Void = {print($0)}
var fn1: (A|B)->Void = {print(v0)}
let a = A()
let b = B()

So:

fn0( a ) // this is OK
fn1( a ) // this is also OK

fn1 is subtype of fn0, because fn1 can do anything fn0 do.
Thus fn0 = fn1 is OK.

But:

fn1( b ) // this is OK
fn0( b ) // this is not OK

So fn0 is not subtype of fn1

At 2016-08-11 10:41:02, "Step C" <schristopher@bignerdranch.com <mailto:schristopher@bignerdranch.com>> wrote:
Shouldn't it be "fn1 = fn0"? Same for the fn2 statements.

`var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}

fn0 = fn1 // OK, because Original Type and Union Type has a sub-typing relationship var

fn2: (A|B|C)->Void = {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK`

On Aug 10, 2016, at 9:28 PM, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I want to make a discussion about union type for swift 4.
See https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md

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

<https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md#detailed-design>\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

Charlie_Monroe1 · 2016-08-11T05:12:16.000Z

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?

···

On Aug 11, 2016, at 5:55 AM, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

Union type is powerful. It can make up optional, let it leaves terrible generic wrap.

And the most important part, It can replace enum Optional<T> to represent optional types.
    let string: String?
is same to

    let string: String | None
instead of

    let string: Optional<String>
IUO, Implicity Unwrapped Optional, can also use union to represent
    let string: String!
will be the same as the union grammar:

    let iuo: *String | None

在 2016年8月11日，11:15，Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> 写道：

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

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

Detail explain:

var fn0: A->Void = {print($0)}
var fn1: (A|B)->Void = {print(v0)}
let a = A()
let b = B()

So:

fn0( a ) // this is OK
fn1( a ) // this is also OK

fn1 is subtype of fn0, because fn1 can do anything fn0 do.
Thus fn0 = fn1 is OK.

But:

fn1( b ) // this is OK
fn0( b ) // this is not OK

So fn0 is not subtype of fn1

At 2016-08-11 10:41:02, "Step C" <schristopher@bignerdranch.com <mailto:schristopher@bignerdranch.com>> wrote:
Shouldn't it be "fn1 = fn0"? Same for the fn2 statements.

`var fn0: A->Void = {print(v0)}
var fn1: (A|B)->Void = {print(v0)}

fn0 = fn1 // OK, because Original Type and Union Type has a sub-typing relationship var

fn2: (A|B|C)->Void = {print($0)}

fn0 = fn2 // OK
fn1 = fn2 // OK`

On Aug 10, 2016, at 9:28 PM, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I want to make a discussion about union type for swift 4.
See https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md

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

<https://github.com/frogcjn/swift-evolution/blob/master/proposals/xxxx-union-type.md#detailed-design>\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

Wallacy · 2016-08-11T13:42:59.000Z

You don't need to act like a jerk. It's really difficult ask to you follow
the past discussions?

Compositions type are "generally" well accepted for this community, but has
some problems to be solved first.

···

Em qui, 11 de ago de 2016 às 02:53, Cao, Jiannan via swift-evolution < swift-evolution@swift.org> escreveu:

OK. I'll shut up since I waste your time.

At 2016-08-11 13:41:59, "Chris Lattner" <clattner@apple.com> wrote:

You’re certainly welcome to your opinion.

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.

-Chris

On Aug 10, 2016, at 10:22 PM, Cao, Jiannan <frogcjn@163.com> wrote:

Swift evolution seems not an evolution.

I'll leave this mail list since this is not a good proposal environment.
Typescript and other language community is more open to new idea.
Swift-evolution is just a weird community.

在 2016-08-11 13:18:54，"Chris Lattner" <clattner@apple.com> 写道：

On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

I don't know if the core team feels differently now with respect to Swift
4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

There is no change in opinion here. This topic is also out of scope for
Swift 4 stage 1 in any case.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

frogcjn · 2016-08-11T14:52:08.000Z

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.

···

在 2016年8月11日，21:42，Wallacy <wallacyf@gmail.com> 写道：

You don't need to act like a jerk. It's really difficult ask to you follow the past discussions?

Compositions type are "generally" well accepted for this community, but has some problems to be solved first.

Em qui, 11 de ago de 2016 às 02:53, Cao, Jiannan via swift-evolution <swift-evolution@swift.org> escreveu:
OK. I'll shut up since I waste your time.

At 2016-08-11 13:41:59, "Chris Lattner" <clattner@apple.com> wrote:
You’re certainly welcome to your opinion.

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.

-Chris

On Aug 10, 2016, at 10:22 PM, Cao, Jiannan <frogcjn@163.com> wrote:

Swift evolution seems not an evolution.

I'll leave this mail list since this is not a good proposal environment. Typescript and other language community is more open to new idea. Swift-evolution is just a weird community.

在 2016-08-11 13:18:54，"Chris Lattner" <clattner@apple.com> 写道：

On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

There is no change in opinion here. This topic is also out of scope for Swift 4 stage 1 in any case.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

griotspeak · 2016-08-17T23:11:59.000Z

These are a couple comments from Chris Lattner that come to mind

"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"

···

On Wed, Aug 17, 2016 at 7:06 PM, Karl via swift-evolution < swift-evolution@swift.org> wrote:

On 11 Aug 2016, at 07:18, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

I don't know if the core team feels differently now with respect to Swift
4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

There is no change in opinion here. This topic is also out of scope for
Swift 4 stage 1 in any case.

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

Thanks

Karl

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Tino · 2016-08-19T16:07:20.000Z

Hi Cao,

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.

- Tino

Johannes_Neubauer1 · 2016-08-11T15:11:31.000Z

Dear Jiannan,

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).

All the best
Johannes

···

Am 11.08.2016 um 16:52 schrieb Cao, Jiannan via swift-evolution <swift-evolution@swift.org>:

在 2016年8月11日，21:42，Wallacy <wallacyf@gmail.com> 写道：

You don't need to act like a jerk. It's really difficult ask to you follow the past discussions?

Compositions type are "generally" well accepted for this community, but has some problems to be solved first.

Em qui, 11 de ago de 2016 às 02:53, Cao, Jiannan via swift-evolution <swift-evolution@swift.org> escreveu:
OK. I'll shut up since I waste your time.

At 2016-08-11 13:41:59, "Chris Lattner" <clattner@apple.com> wrote:
You’re certainly welcome to your opinion.

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.

On Aug 10, 2016, at 10:22 PM, Cao, Jiannan <frogcjn@163.com> wrote:

Swift evolution seems not an evolution.

I'll leave this mail list since this is not a good proposal environment. Typescript and other language community is more open to new idea. Swift-evolution is just a weird community.

在 2016-08-11 13:18:54，"Chris Lattner" <clattner@apple.com> 写道：

On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

I don't know if the core team feels differently now with respect to Swift 4, but union types are listed as a "commonly rejected change":

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

There is no change in opinion here. This topic is also out of scope for Swift 4 stage 1 in any case.

xwu · 2016-08-19T16:25:19.000Z

Hi Cao,

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."

···

On Fri, Aug 19, 2016 at 11:07 AM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:

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.

- Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution