Re: [swift-evolution] [swift-dev] Make offset index available for String

[Cao, Jiannan via swift-evolution]

Sorry for my unclear "offset indexable".
So what I mean by "offset indexable" is providing a "collection-element level 
offset indexing". This indexing could provide to any collection, because it is 
the basic concept of collections.
The unicode offset is different than it and is important to String. Thus I just 
want the team to consider providing collections with the collection-element 
level offset indexing as an assistant to String.Index (which is the unicode 
level offset indexing).

> 在 2017年12月15日，上午9:34，Michael Ilseman  > 写道：
> 
> Yes, I was trying to highlight that they are different and should be treated 
> different. This was because it seemed you were conflating the two in your 
> argument. You claim that people expect it, and I’m pointing out that what 
> people actually expect (assuming they’re coming from C or languages with a 
> similar model) already exists as those models deal in encoded offsets.
> 
> More important than expectations surrounding what to provide to a subscript 
> are expectations surrounding algorithmic complexity. This has security 
> implications. The expectation of subscript is that it is “constant-ish”, for 
> a fuzzy hand-wavy definition of “constant-ish” which includes amortized 
> constant or logarithmic.
> 
> Now, I agree with the overall sentiment that `index(offsetBy:)` is unwieldy. 
> I am interested in approaches to improve this. But, we cannot throw linear 
> complexity into subscript without extreme justification.
> 
> 
>> On Dec 14, 2017, at 5:25 PM, Cao, Jiannan > > wrote:
>> 
>> This offset is unicode offset, is not the offset of element. 
>> For example: index(startIndex, offsetBy:1) is encodedOffset 4 or 8, not 1.
>> 
>> Offset indexable is based on the offset of count of each element/index. it 
>> is the same result of s.index(s.startIndex, offsetBy:i)
>> The encodedOffset is the underlaying offset of unicode string, not the same 
>> concept of the offset index of collection.
>> 
>> The offset indexable is meaning to the elements and index of collection 
>> (i-th element of the collection), not related to the unicode offset (which 
>> is the underlaying data offset meaning to the UTF-16 String).
>> 
>> These two offset is totally different.
>> 
>> Best,
>> Jiannan
>> 
>>> 在 2017年12月15日，上午9:17，Michael Ilseman >> > 写道：
>>> 
>>> 
>>> 
 On Dec 14, 2017, at 4:49 PM, Cao, Jiannan via swift-dev 
 mailto:swift-...@swift.org>> wrote:
 
 People used to the offset index system instead of the String.Index. Using 
 offset indices to name the elements, count the elements is normal and 
 nature.
 
>>> 
>>> The offset system that you’re referring to is totally available in String 
>>> today, if you’re willing for it to be the offset into the encoding. That’s 
>>> the offset “people” you’re referring to are likely used to and consider 
>>> normal and natural. On String.Index, there is the following:
>>> 
>>> init(encodedOffset offset: Int 
>>> )
>>> 
>>> and 
>>> 
>>> var encodedOffset: Int 
>>>  { get }
>>> 
>>> 
>>> [1] https://developer.apple.com/documentation/swift/string.index 
>>> 
>>> 
>>> 
 This offset index system has a long history and a real meaning to the 
 collection. The subscript s[i] has a fix meaning of "getting the i-th 
 element in this collection", which is normal and direct. Get the range 
 with offset indices, is also direct. It means the substring is from the 
 i-th character up to the j-th character of the original string.
 
 People used to play subscript, range with offset indices. Use 
 string[string.index(i, offsetBy: 5)] is not as directly and easily as 
 string[i + 5]. Also the Range is not as directly as 
 Range. Developers need to transfer the Range result 
 of string.range(of:) to Range to know the exact range of the 
 substring. Range has a real meaning to the machine and 
 underlaying data location for the substring, but Range also 
 has a direct location information for human being, and represents the 
 abstract location concept of the collection (This is the most 
 UNIMPEACHABLE REASON I could provide).
 
 Offset index system is based on the nature of collection. Each element of 
 the collection could be located by offset, which is a direct and simple 
 conception to any collection. Right? Even the String with String.Index has 
 some offset index property within it. For example: the `count` of the 
 String, is the offset index of the endIndex.The enumerated() generated a 
 sequence with elements contains the same offset as the offset index system 
 provided. And when we apply Array(string), the string divided by each 
 character and make the offset indices available f

Re: [swift-evolution] array splatting for variadic parameters

[Cao, Jiannan via swift-evolution]

What about calling a framework variadic function that I could not re-declare?
like print

> 在 2017年12月2日，上午1:26，Tino Heth <2...@gmx.de <mailto:2...@gmx.de>> 写道：
> 
> There has been a solution to the same problem that’s imho much nicer, because 
> instead of adding fundamental new syntax, it removes a piece of C-legacy:
> 
> Basically,instead of
> func f(args: Int…)
> you would just declare
> func f(args: @variadic [Int])
> or even
> func f(args: [Int])
> and interpret any argument that’s a comma-separated list as an array — or, 
> and that’s imho another useful aspect, something else that can be expressed 
> with an array literal
> func f(args: Set)
> 
> So you would not only make the language surface smaller, but also add new 
> abilities that basically come for free (they would still have to be 
> implemented, though ;-)
> 
>> Am 30.11.2017 um 22:13 schrieb Cao, Jiannan via swift-evolution 
>> mailto:swift-evolution@swift.org>>:
>> 
>> What happened with this proposal? This looks easy to implement.
>> 
>> func sumOf(numbers: Int...) -> Int {
>>   ...
>>   }
>> typealias Function = [Int] -> Int
>> let sumOfArray = unsafeBitCast(sumOf, Function.self)
>> sumOfArray([1, 2, 3])
>> 
>>> Hello everyone.
>>> 
>>> I understand that topic has already been discussed in the past, but I 
>>> failed to get any information on its current state of affairs.
>>> 
>>> I guess the subject of this mail is explicit, but to make sure I’m clear, 
>>> here's a small snippet that illustrates the problem:
>>> 
>>> func f(args: Int…) {
>>>   // Some implementation ...
>>> }
>>> // Now it's impossible to call f without explicitly naming its parameters.
>>> 
>>> For many use-cases, this problem can be solved by overloading f so that it 
>>> explicitly accepts an array.
>>> 
>>> func f(_ args: [Int]) {
>>>   // Some implementation ...
>>> }
>>> 
>>> func f(_ args: Int…) {
>>>   f(args)
>>> }
>>> 
>>> Some people also advocate (myself generally included) that one should 
>>> prefer the signature explicitly marking args as an array, as the syntactic 
>>> overhead of wrapping the arguments with “[]” when calling f is arguably 
>>> bearable. However, in some other situations, this approach might not be 
>>> applicable. For instance, one may simply not be able to modify the original 
>>> function. Another use-case may be a function that should forward its own 
>>> variadic parameters.
>>> 
>>> In a variety of other languages, there exists a way to do this. For 
>>> instance, Python can “unpack” (or splat) a list into function arguments by 
>>> prefixing it with *:
>>> 
>>> def f(*args):
>>>   # Some implementation …
>>> 
>>> f(*[1, 2, 3]) # == f(1, 2, 3)
>>> 
>>> I was wondering if such feature could be supported by Swift, and if not, 
>>> why.
>>> 
>>> Syntactically, I like the use of “…”, which would mirror function 
>>> signatures:
>>> 
>>> f(…[1, 2, 3]) // == f(1, 2, 3)
>>> 
>>> Thanks.
>>> 
>>> --
>>> Dimitri Racordon
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

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

Re: [swift-evolution] array splatting for variadic parameters

[Cao, Jiannan via swift-evolution]

What happened with this proposal? This looks easy to implement.

func sumOf(numbers: Int...) -> Int {
  ...
  }
typealias Function = [Int] -> Int
let sumOfArray = unsafeBitCast(sumOf, Function.self)
sumOfArray([1, 2, 3])

> Hello everyone.
> 
> I understand that topic has already been discussed in the past, but I failed 
> to get any information on its current state of affairs.
> 
> I guess the subject of this mail is explicit, but to make sure I’m clear, 
> here's a small snippet that illustrates the problem:
> 
> func f(args: Int…) {
>   // Some implementation ...
> }
> // Now it's impossible to call f without explicitly naming its parameters.
> 
> For many use-cases, this problem can be solved by overloading f so that it 
> explicitly accepts an array.
> 
> func f(_ args: [Int]) {
>   // Some implementation ...
> }
> 
> func f(_ args: Int…) {
>   f(args)
> }
> 
> Some people also advocate (myself generally included) that one should prefer 
> the signature explicitly marking args as an array, as the syntactic overhead 
> of wrapping the arguments with “[]” when calling f is arguably bearable. 
> However, in some other situations, this approach might not be applicable. For 
> instance, one may simply not be able to modify the original function. Another 
> use-case may be a function that should forward its own variadic parameters.
> 
> In a variety of other languages, there exists a way to do this. For instance, 
> Python can “unpack” (or splat) a list into function arguments by prefixing it 
> with *:
> 
> def f(*args):
>   # Some implementation …
> 
> f(*[1, 2, 3]) # == f(1, 2, 3)
> 
> I was wondering if such feature could be supported by Swift, and if not, why.
> 
> Syntactically, I like the use of “…”, which would mirror function signatures:
> 
> f(…[1, 2, 3]) // == f(1, 2, 3)
> 
> Thanks.
> 
> --
> Dimitri Racordon

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

[swift-evolution] [Bug] Foundation.URL should support semicolon(; ) appearing in URL path

[Cao, Jiannan via swift-evolution]

http://host/book;id=1/page;2/

this URL is a valid URL, but URLComponents will ruin it with %3B
http://host/book%3Bid=1/page%3B2/

Since Swift Server is coming out, this bug should be solved.


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

[swift-evolution] [Pitch] allow non-nominal type extension

[Cao Jiannan via swift-evolution]

It is just same as current grammar:

extension TrackCountProvider where Self : PublishDateProvider { ... }

with a more logical format

extension TrackCountProvider & PublishDateProvider { ... }

> e.g.
> 
> extensionTrackCountProvider&PublishDateProvider{
> vartrackCountAndPublishDateText:String{
> varinfos: [String] = []
> 
> iflettrackCount = trackCount{
> infos.append("\(trackCount)")
> 
> }
> 
> ifletpublishDateText = publishDate?.text {
> infos.append(publishDateText)
> }
> 
> returninfos.joined(separator: seperator)
> }
> }
> 
> 
> 
> 
> ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] allow non-nominal type extension

[Cao Jiannan via swift-evolution]

e.g.

extension TrackCountProvider & PublishDateProvider {
var trackCountAndPublishDateText: String {
var infos: [String] = []

if let trackCount = trackCount  {
infos.append("\(trackCount)")
}

if let publishDateText = publishDate?.text {
infos.append(publishDateText)
}

return infos.joined(separator: seperator)
}
}

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

[swift-evolution] [Pich] allow embed type declaration in protocol & allow throw in property getter/setter

[Cao Jiannan via swift-evolution]

1. allow embed type declaration in protocol
e.g.:

protocol URLProvider {
fun url() throws -> URL
}

extension URLProvider {
enum Error: Swift.Error {
 invalidBaseURL
 invalidPath
 invalidQuery
 invalidFragment
}
}


 func parseURL() throws -> URL {
throw URLProvider.Error.invalidBaseURL
}

2. allow throw in property getter/setter

e.g.:

struct myURLProvider: URLProvider {
var url: throws -> URL {
try URL(baseURL: baseURL, path: path, query: query, fragment: fragment)
}
}


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

Re: [swift-evolution] [Pitch] inout with capture variable

[Cao Jiannan via swift-evolution]

I just want to demo how the inout capture works.
the demo code just want to capture value avoiding capture self.


> > On Oct 5, 2016, at 10:07 PM, Cao 
> > Jiannanmailto:frog...@163.com)>wrote:
> > so if developer want to capture an variable inference, must declare a new 
> > variable.
> I don’t follow what you mean here.
> 
> > 
> > classA {
> > varvalue = 1
> > 
> > functest() ->() ->Int{
> > varcapturedValue =self.value
> > leteditInfo = { () ->Intin
> > capturedValue += 1
> > returncapturedValue
> > }
> > returneditInfo
> > }
> > }
> > 
> > leta =A()
> > 
> > leteditInfo =a.test()
> > print(editInfo()) // 2
> > print(a.value) // 1
> > 
> > print(editInfo()) // 3
> > 
> > print(a.value) // 1
> > 
> > what about:
> > 
> > classA {
> > varvalue = 1
> > 
> > functest() ->() ->Int{
> > leteditInfo = { [inout value] () ->Intin
> > capturedValue += 1
> > returncapturedValue
> > }
> > returneditInfo
> > }
> > }
> > 
> > leta =A()
> > 
> > leteditInfo =a.test()
> > print(editInfo()) // 2
> > print(a.value) // 2
> > 
> > 
> > print(editInfo()) // 3
> > 
> > print(a.value) // 3
> > 
> > 
> > 
> > 
> I’m not quite sure what you’re getting at, but this prints what you’re 
> expecting in the output you have in the comments:
> 
> class A {
> var value = 1
> 
> func test() ->() ->Int {
> let editInfo = { () ->Int in
> self.value += 1
> return self.value
> }
> return editInfo
> }
> }
> 
> let a = A()
> 
> let editInfo = a.test()
> print(editInfo()) // 2
> print(a.value) // 2
> print(editInfo()) // 3
> print(a.value) // 3
> 
> 
> Mark
> 
> > 
> > >>On Oct 5, 2016, at 9:06 PM, Cao Jiannan via 
> > >>swift-evolutionmailto:swift-evolution@swift.org)>wrote:
> > >>
> > >>for example:
> > >>
> > >>var a = 1
> > >>
> > >>let block = { [inout a] in
> > >>a += 1
> > >>}
> > >>
> > >>block()
> > >>block()
> > >>
> > >>print(a) // 3
> > >This is already how captures work by default in closures and nested 
> > >functions in Swift:
> > >
> > >var a = 1
> > >
> > >let block = { a += 1 }
> > >
> > >block()
> > >block()
> > >
> > >print(a) // prints 3
> > >
> > >
> > >If you want to capture something immutably you can put it in the capture 
> > >list:
> > >
> > >var a = 1
> > >let block = { [a] in a += 1 } // error: left side of mutating operator 
> > >isn't mutable: 'a' is a 'let' constant
> > >
> > >Mark
> > >
> > >>
> > >>
> > >>___
> > >>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

Re: [swift-evolution] [Pitch] inout with capture variable

[Cao Jiannan via swift-evolution]

so if developer want to capture an variable inference, must declare a new 
variable.

class A {
var value = 1

func test() -> () -> Int {
var capturedValue = self.value
let editInfo = { () -> Int in 
capturedValue += 1
return capturedValue
}
return editInfo
}
}

let a = A()

let editInfo = a.test()
print(editInfo()) // 2
print(a.value) // 1
print(editInfo()) // 3
print(a.value) // 1

what about:

class A {
var value = 1

func test() -> () -> Int {
let editInfo = { [inout value] () -> Int in 
capturedValue += 1
return capturedValue
}
return editInfo
}
}

let a = A()

let editInfo = a.test()
print(editInfo()) // 2
print(a.value) // 2
print(editInfo()) // 3
print(a.value) // 3

> > On Oct 5, 2016, at 9:06 PM, Cao Jiannan via 
> > swift-evolutionwrote:
> > 
> > for example:
> > 
> > var a = 1
> > 
> > let block = { [inout a] in
> > a += 1
> > }
> > 
> > block()
> > block()
> > 
> > print(a) // 3
> This is already how captures work by default in closures and nested functions 
> in Swift:
> 
> var a = 1
> 
> let block = { a += 1 }
> 
> block()
> block()
> 
> print(a) // prints 3
> 
> 
> If you want to capture something immutably you can put it in the capture list:
> 
> var a = 1
> let block = { [a] in a += 1 } // error: left side of mutating operator isn't 
> mutable: 'a' is a 'let' constant
> 
> Mark
> 
> > 
> > 
> > ___
> > 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

[swift-evolution] [Pitch] inout with capture variable

[Cao Jiannan via swift-evolution]

for example:

var a = 1

let block = { [inout a] in
a += 1
}

block()
block()

print(a) // 3


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

[swift-evolution] [Pitch] Several improvements points about extension and typealias

[Cao, Jiannan via swift-evolution]

1. Allow extension specific dictionary
e.g.
extension Dictionary where Key == String, Value == String
or
extension Dictionary

2. Allow extending Equatable internally
currently any type extend to Equatable should make theme public

3. Allow internal typealias for a public type
this internal typealias will only can be used in that package.

Thanks

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

[swift-evolution] [Pitch] allow define submodule in Foundation or file group like Swift Standard Library?

[Cao Jiannan via swift-evolution]

I notice that Swift Standard Library using GroupInfo to define group of swift 
files. And Xcode can show that group in editor. e.g. Math.

Will Apple allow Swift developer to define group in their own framework? So 
they can see the special generated type information instead of a long file.

In Foundation, there are submodules inherits from C headers. Will Apple allow 
Swift developer to define submodule in their own framework?
 e.g. import MyFoundation.Math

Thanks!


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

[swift-evolution] [Pitch] improve import sentence: allow import specific nested types

[Cao Jiannan via swift-evolution]

Now Swift 3 allow us import specific enum/struct from module, but it only allow 
us import top-level declaration.

For example:

in MyFoudnation framework:

public struct Time {
public struct DateOnly {}
}

in App target:
I can only
 
import struct MyFoundation.Time

But I cannot 

import struct MyFoundation.Time.DateOnly

So allow developer import nested types

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

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Cao, Jiannan via swift-evolution]

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  写道：
> 
> 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 
>>  escreveu:
>> OK. I'll shut up since I waste your time.
>> 
>> At 2016-08-11 13:41:59, "Chris Lattner"  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  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"  写道：
>>>> 
>>>> On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution 
>>>>  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Cao, Jiannan via swift-evolution]

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


At 2016-08-11 13:41:59, "Chris Lattner"  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  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"  写道：


On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution 
 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

Re: [swift-evolution] [Accepted] SE-0091: Improving operator requirements in protocols

[Cao Jiannan via swift-evolution]

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

> 在 2016年7月14日，12:56，Chris Lattner via swift-evolution 
>  写道：
> 
> 
>> On Jul 13, 2016, at 8:57 PM, Tony Allevato > > wrote:
>> 
>> Thanks Chris! I'm happy that the proposal was well-received, and thanks to 
>> Doug for the great improvements for revision 2.
>> 
>> Related, does the acceptance of this proposal imply the removal of the named 
>> methods from FloatingPoint and Arithmetic in favor of static operators, or 
>> do we need a separate proposal for that?
> 
> That should be either a separate proposal or a refinement to this one.  I 
> suspect we’ll go with the later approach just because the changes are 
> “obvious”, but I don’t speak for the whole core team with that opinion.
> 
> -Chris
> 
> 
>> 
>> I'll work on a PR to the proposal that covers the changes regarding classes, 
>> and to list the protocols affected by this (FP and Arithmetic noted above, 
>> as well as Equatable and others).
>> 
>> On Wed, Jul 13, 2016 at 8:46 PM Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
>>  
>> 
>> 
>> The second review of "SE-0091: Improving operator requirements in protocols" 
>> ran from July 7...12, 2016. The proposal has been *accepted with revision*:
>> 
>> The second iteration of this proposal has been very well received by both 
>> the community and core team.  The core team requests one minor modification: 
>> in an effort to reduce the scope of the proposal, it should specifically 
>> require that operator declarations in classes be written as static (or 
>> equivalently, as “final class”).  In the future, support for operators may 
>> be extended to support dynamic dispatch, and the core team wants to keep the 
>> design space open.  The core team also observed that the impact on the 
>> standard library is not captured in this proposal, but that can be 
>> incorporated later (as an amendment to this proposal) since it should have 
>> little user impact.
>> 
>> Thank you to Tony Allevato and Doug Gregor for driving this discussion 
>> forward!  I filed SR-2073 to track implementation work on this.
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> 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

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

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Cao, Jiannan via swift-evolution]

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"  写道：


On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution 
 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

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Cao Jiannan via swift-evolution]

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 to represent 
optional types.
let string: String?
is same to

let string: String | None
instead of

let string: Optional
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  写道：
> 
> 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 
> <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 
> 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"  <mailto:schristop...@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 
> 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/-union-type.md
>>  
>> <https://github.com/frogcjn/swift-evolution/blob/master/proposals/-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/-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 
>> <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 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

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

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Cao Jiannan via swift-evolution]

https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000182.html
 
<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  写道：
> 
> 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 
> <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 
> 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"  <mailto:schristop...@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 
> 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/-union-type.md
>>  
>> <https://github.com/frogcjn/swift-evolution/blob/master/proposals/-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/-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 
>> <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 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

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

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Cao, Jiannan via swift-evolution]

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

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





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

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

[Cao Jiannan via swift-evolution]

Hi all,

I want to make a discussion about union type for swift 4.
See 
https://github.com/frogcjn/swift-evolution/blob/master/proposals/-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

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

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao Jiannan via swift-evolution]

If you like, you can try to modify your code as you writes. It is crazy.

> 在 2016年7月10日，00:08，Austin Zheng via swift-evolution 
>  写道：
> 
>> 
>> On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>> On 9 Jul 2016, at 00:53, Jon Shier > > wrote:
>> 
>>> While I can see why removing the labels from the type system would be a 
>>> good idea, I don’t see why calling the functions with labels would be 
>>> actively prohibited. That’s useful information for the developer to have, 
>>> and if the compiler doesn’t know them in some way, you can be assured 
>>> Xcode’s autocomplete won’t see them. 
>> 
>> I wish the core team or the author of the proposal came to this thread and 
>> engaged again with the community. 
> 
> I'm not inclined to spend time engaging with people who couldn't be bothered 
> to give feedback during the week-long official review period.
> 
>> 
>> I imagine scenarios of callbacks, say for an image downloader or something 
>> that ought to happen asynchronously, injected in a method, stored, and then 
>> used when the asynchronous operation completed one way or the other. 
>> How does this promote local reasoning so much stressed by Apple itself at 
>> WWDC when you have to jump through several hoops to have any idea what the 
>> callbacks does or what parameters and in which order it needs them?
> 
> If you really want to promote local reasoning, write short methods and look 
> at the function signature, where you can stick labels. Or use the type system 
> or typealiases.
> 
> A better solution might be the compound function names that came up during 
> both the review thread and this thread (e.g. let foo(with:for:) : (Int, Int) 
> -> Bool = blah). Those were going to be added to the original proposal during 
> private review, but were nixed. If someone feels strongly enough about the 
> issue, they should submit a PR for a proposal amendment or a follow-up 
> proposal.
> 
>> 
>> The benefits to the compiler should be weighed against the negative effects 
>> to every day's code and the bugs this may introduce in a safe by default 
>> promise language like Swift.
>> 
 On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 I still say that this is the case where we do take a stand and do ask for 
 this proposal to be blocked and re-analised, I cannot believe that we are 
 going to be addingthis kind of incosistency to the language and take 
 readability/ease of local reasoning (which Apple stressed at the last WWDC 
 once again) away. The community and the core team just finished 
 bikeshedding a huge change to how API's are imported and how labels are 
 used and how important they are and then we do this?
 
 On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> Aw. It's really bad that labels are gone for closures at the call site 😢. 
> IMHO, the same principles that encourage the use of labels for "normal" 
> function calls should prevail here. 
 No need to feel bad — if I wasn't ignored (it's hard to notice if this 
 happens ;-), the argument has been considered.
 
 Additionally, those labels may return in the future — although there is a 
 astoundingly long list of features that will be removed because their 
 implementation is flawed, and whose fans have been calmed down with the 
 argument that they'll be re-added in an improved form later ;-)
 
 ___
 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 
 
>>> 
>> ___
>> 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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao Jiannan via swift-evolution]

func needsCallback(callback: (a: Int, b: Int) -> Void) {
callback(a: 1,b: 2)
}


func needsCallback(callback: (Int, Int) -> Void) {
callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?


> 在 2016年7月7日，11:06，Chris Lattner via swift-evolution 
>  写道：
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
> 
> The review of "SE-0111: Remove type system significance of function argument 
> labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:
> 
> The community and core team agree that this proposal will lead to a 
> simplification and clarification of the type system, as well as a more clear 
> user model for parameter labels.  In response to community feedback, the core 
> team is accepting the proposal with a revision to allow “purely cosmetic” 
> parameter labels in closure types for documentation (as outlined in the 
> alternatives section).  The core team also wants to clarify that a call to a 
> value of closure type would not allow use of any parameter labels, some 
> interpretations thought that “arbitrary” parameter labels could be used.
> 
> Thank you to Austin Zheng for driving this discussion forward!  I filed 
> SR-2009 to track implementation work on this.
> 
> -Chris Lattner
> Review Manager
> 
> ___
> 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

[swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao, Jiannan via swift-evolution]

I'd rather like

let bar = foo as (a:c:)

to limit the possibility of bar not uncleared way. 
> 
>> 在 2016年7月7日，12:11，Félix Cloutier  写道：
>> 
>> I personally find that { foo(a: $0, c: $1) } is an already simple enough way 
>> to solve that problem.
>> 
>> Félix
>> 
>>> Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution 
>>>  a écrit :
>>> 
>>> l'd like the way of Python to handle the function signature.Assign lost 
>>> other possibility of that function:
>>> 
>>> foo(b:c:)
>>> foo(a:c:)
>>> foo(a:b:)
>>> foo(a:)
>>> foo(b:)
>>> foo(c:)
>>> foo()
>>> 
>>> very weird.
>>> 
>>> 
>>> 
>>>>> 在 2016年7月7日，11:36，Douglas Gregor  写道：
>>>>> 
>>>>> 
>>>>> On Jul 6, 2016, at 8:34 PM, frog...@163.com wrote:
>>>>> 
>>>>> so how you call bar and get default values for a, b, c?
>>>> 
>>>> You don’t.
>>>> 
>>>>> why lost default value for that function? it is wired.
>>>> 
>>>> Default values aren’t part of a function type. While it is possible to 
>>>> come up with such designs, there is little precedent for them and doing so 
>>>> either drastically limits what kinds of default arguments can be expressed 
>>>> or causes values of function type to become large (so they can encode the 
>>>> computation of the default values).
>>>> 
>>>>   - Doug
>>>> 
>>>>> 
>>>>>>> 在 2016年7月7日，11:29，Douglas Gregor  写道：
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Don't agree with this one.
>>>>>>> 
>>>>>>> func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
>>>>>>> print(a, b, c)
>>>>>>> }
>>>>>>> 
>>>>>>> foo(a: 1, c: 3)
>>>>>>> 
>>>>>>> let bar = foo
>>>>>>> 
>>>>>>> bar(1, 3) will different than foo(a: 1, c: 3)
>>>>>> 
>>>>>> bar(1, 3) will result in an error, because “bar” is of type 
>>>>>> 
>>>>>> (Int, Int, Int) -> Void
>>>>>> 
>>>>>> Default arguments are associated with function declarations, not 
>>>>>> function types.
>>>>>> 
>>>>>> - Doug
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> 在 2016年7月7日，11:06，Chris Lattner  写道：
>>>>>>>> 
>>>>>>>> Proposal Link: 
>>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>>>>>>>> 
>>>>>>>> The review of "SE-0111: Remove type system significance of function 
>>>>>>>> argument labels " ran from June 30 ... July 4, 2016. The proposal has 
>>>>>>>> been *accepted*:
>>>>>>>> 
>>>>>>>> The community and core team agree that this proposal will lead to a 
>>>>>>>> simplification and clarification of the type system, as well as a more 
>>>>>>>> clear user model for parameter labels.  In response to community 
>>>>>>>> feedback, the core team is accepting the proposal with a revision to 
>>>>>>>> allow “purely cosmetic” parameter labels in closure types for 
>>>>>>>> documentation (as outlined in the alternatives section).  The core 
>>>>>>>> team also wants to clarify that a call to a value of closure type 
>>>>>>>> would not allow use of any parameter labels, some interpretations 
>>>>>>>> thought that “arbitrary” parameter labels could be used.
>>>>>>>> 
>>>>>>>> Thank you to Austin Zheng for driving this discussion forward!  I 
>>>>>>>> filed SR-2009 to track implementation work on this.
>>>>>>>> 
>>>>>>>> -Chris Lattner
>>>>>>>> Review Manager
>>>>>>>> 
>>>>>>>> ___
>>>>>>>> swift-evolution-announce mailing list
>>>>>>>> swift-evolution-annou...@swift.org
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>>>>>> 
>>>>>>> 
>>>>>>> ___
>>>>>>> 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
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao, Jiannan via swift-evolution]

l'd like the way of Python to handle the function signature.Assign lost other 
possibility of that function:

foo(b:c:)
foo(a:c:)
foo(a:b:)
foo(a:)
foo(b:)
foo(c:)
foo()

very weird.



> 在 2016年7月7日，11:36，Douglas Gregor  写道：
> 
> 
>> On Jul 6, 2016, at 8:34 PM, frog...@163.com wrote:
>> 
>> so how you call bar and get default values for a, b, c?
> 
> You don’t.
> 
>> why lost default value for that function? it is wired.
> 
> Default values aren’t part of a function type. While it is possible to come 
> up with such designs, there is little precedent for them and doing so either 
> drastically limits what kinds of default arguments can be expressed or causes 
> values of function type to become large (so they can encode the computation 
> of the default values).
> 
>- Doug
> 
>> 
>>> 在 2016年7月7日，11:29，Douglas Gregor  写道：
>>> 
>>> 
>>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution 
>>>>  wrote:
>>>> 
>>>> Don't agree with this one.
>>>> 
>>>> func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
>>>> print(a, b, c)
>>>> }
>>>> 
>>>> foo(a: 1, c: 3)
>>>> 
>>>> let bar = foo
>>>> 
>>>> bar(1, 3) will different than foo(a: 1, c: 3)
>>> 
>>> bar(1, 3) will result in an error, because “bar” is of type 
>>> 
>>>  (Int, Int, Int) -> Void
>>> 
>>> Default arguments are associated with function declarations, not function 
>>> types.
>>> 
>>>  - Doug
>>> 
>>> 
>>>> 
>>>>> 在 2016年7月7日，11:06，Chris Lattner  写道：
>>>>> 
>>>>> Proposal Link: 
>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>>>>> 
>>>>> The review of "SE-0111: Remove type system significance of function 
>>>>> argument labels " ran from June 30 ... July 4, 2016. The proposal has 
>>>>> been *accepted*:
>>>>> 
>>>>> The community and core team agree that this proposal will lead to a 
>>>>> simplification and clarification of the type system, as well as a more 
>>>>> clear user model for parameter labels.  In response to community 
>>>>> feedback, the core team is accepting the proposal with a revision to 
>>>>> allow “purely cosmetic” parameter labels in closure types for 
>>>>> documentation (as outlined in the alternatives section).  The core team 
>>>>> also wants to clarify that a call to a value of closure type would not 
>>>>> allow use of any parameter labels, some interpretations thought that 
>>>>> “arbitrary” parameter labels could be used.
>>>>> 
>>>>> Thank you to Austin Zheng for driving this discussion forward!  I filed 
>>>>> SR-2009 to track implementation work on this.
>>>>> 
>>>>> -Chris Lattner
>>>>> Review Manager
>>>>> 
>>>>> ___
>>>>> swift-evolution-announce mailing list
>>>>> swift-evolution-annou...@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>>> 
>>>> 
>>>> ___
>>>> 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

[swift-evolution] Fwd: [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao, Jiannan via swift-evolution]

so how you call bar and get default values for a, b, c? why lost default value 
for that function? it is wired.
> 
>> 在 2016年7月7日，11:29，Douglas Gregor  写道：
>> 
>> 
>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution 
>>>  wrote:
>>> 
>>> Don't agree with this one.
>>> 
>>> func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
>>>  print(a, b, c)
>>> }
>>> 
>>> foo(a: 1, c: 3)
>>> 
>>> let bar = foo
>>> 
>>> bar(1, 3) will different than foo(a: 1, c: 3)
>> 
>> bar(1, 3) will result in an error, because “bar” is of type 
>> 
>>   (Int, Int, Int) -> Void
>> 
>> Default arguments are associated with function declarations, not function 
>> types.
>> 
>>   - Doug
>> 
>> 
>>> 
>>>> 在 2016年7月7日，11:06，Chris Lattner  写道：
>>>> 
>>>> Proposal Link: 
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>>>> 
>>>> The review of "SE-0111: Remove type system significance of function 
>>>> argument labels " ran from June 30 ... July 4, 2016. The proposal has been 
>>>> *accepted*:
>>>> 
>>>> The community and core team agree that this proposal will lead to a 
>>>> simplification and clarification of the type system, as well as a more 
>>>> clear user model for parameter labels.  In response to community feedback, 
>>>> the core team is accepting the proposal with a revision to allow “purely 
>>>> cosmetic” parameter labels in closure types for documentation (as outlined 
>>>> in the alternatives section).  The core team also wants to clarify that a 
>>>> call to a value of closure type would not allow use of any parameter 
>>>> labels, some interpretations thought that “arbitrary” parameter labels 
>>>> could be used.
>>>> 
>>>> Thank you to Austin Zheng for driving this discussion forward!  I filed 
>>>> SR-2009 to track implementation work on this.
>>>> 
>>>> -Chris Lattner
>>>> Review Manager
>>>> 
>>>> ___
>>>> swift-evolution-announce mailing list
>>>> swift-evolution-annou...@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>> 
>>> 
>>> ___
>>> 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

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao, Jiannan via swift-evolution]

Don't agree with this one.

func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
print(a, b, c)
}

foo(a: 1, c: 3)

let bar = foo

bar(1, 3) will different than foo(a: 1, c: 3)

> 在 2016年7月7日，11:06，Chris Lattner  写道：
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
> 
> The review of "SE-0111: Remove type system significance of function argument 
> labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:
> 
> The community and core team agree that this proposal will lead to a 
> simplification and clarification of the type system, as well as a more clear 
> user model for parameter labels.  In response to community feedback, the core 
> team is accepting the proposal with a revision to allow “purely cosmetic” 
> parameter labels in closure types for documentation (as outlined in the 
> alternatives section).  The core team also wants to clarify that a call to a 
> value of closure type would not allow use of any parameter labels, some 
> interpretations thought that “arbitrary” parameter labels could be used.
> 
> Thank you to Austin Zheng for driving this discussion forward!  I filed 
> SR-2009 to track implementation work on this.
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce


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

[swift-evolution] Fwd: [Proposal] Union Type

[Cao Jiannan via swift-evolution]

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 
> 主题: 回复： [swift-evolution] [Proposal] Union Type
> 日期: 2016年7月2日 GMT+8 01:03:17
> 收件人: Cao Jiannan 
> 抄送: swift-evolution 
> 
>> 
>> On Jul 1, 2016, at 2:08 AM, Cao Jiannan via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> Hi all,
>> 
>> I'm now officially proposal the union type feature for Swift. Please see:
>> 
>> 
>> https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md
>>  
>> <https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md>
>> Introduction
>> 
>> Add union type grammar, represents the type which is one of other types.
>> 
>> var stringOrURL: String | URL = "https://www.apple.com";
>> 
>> 
>> I would be thankful if someone support this idea and give some advice. 
>> Thanks!
> 
> We touch on this in the "commonly proposed" list:
> 
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md 
> <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>
> 
> 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

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

Re: [swift-evolution] [Proposal] Union Type

[Cao Jiannan via swift-evolution]

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 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 func |(_: 
> T.Type, _: U.Type) -> OneOf.Type { // I also use the proposal to remove 
> `.self` magic here return OneOf } // 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.Type, _: OneOf<...U>.Type) -> 
> OneOf.Type { // Copy and merge types into the new `OneOf` type 
> return OneOf } 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 typealias ABCD = ABC | D // 
> merging lhs OneOf with D to OneOf
> 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.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!

> 在 2016年7月1日，21:35，Cao Jiannan  写道：
> 
> what if OneOf?
> 
> duplicate variable compile warning?
> 
>> 在 2016年7月1日，20:59，Adrian Z. > > 写道：
>> 
>> Just one simple thing to add:
>> 
>> If ...T equals 10 then <...T, U> = 10 + 1 = 11 types
>> If ...U equals 17 then  = 1 + 17 = 18 types
>> If ...T equals 20 and ...Uequals 22 then <...T, ...U> = 20 + 22 = 42 types
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub 
>> , 
>> or mute the thread 
>> .
>> 
>>> 
>> 
>>> 在 2016年7月1日，21:33，Cao Jiannan mailto:frog...@163.com>> 写道：
>>> 
>>> 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
 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
 func |(_: T.Type, _: U.Type) -> OneOf.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
 }
 
 // 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.Type, _: OneOf<...U>.Type) -> OneOf.Type {
 
 // Copy and merge types into the new `OneOf` type
 return OneOf
 }
 
 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
 typealias ABCD = ABC | D // merging lhs OneOf with D to OneOf
 Mission accomplished.
 
 
> 在 2016年7月1日，17:06，Cao Jiannan mailto:frog...@163.com>> 
> 写道：
> 
> https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md
>  
> 
> 
> Hi,
> 
> I'm now officially proposal the union type feature for Swift. Please see:
> 
> 
> https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121
>  
> 
> Introduction
> 
> Add 

Re: [swift-evolution] [Proposal] Union Type

[Cao Jiannan via swift-evolution]

what if OneOf?

duplicate variable compile warning?

> 在 2016年7月1日，20:59，Adrian Z.  > 写道：
> 
> Just one simple thing to add:
> 
> If ...T equals 10 then <...T, U> = 10 + 1 = 11 types
> If ...U equals 17 then  = 1 + 17 = 18 types
> If ...T equals 20 and ...Uequals 22 then <...T, ...U> = 20 + 22 = 42 types
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> , 
> or mute the thread 
> .
> 
>> 
> 
>> 在 2016年7月1日，21:33，Cao Jiannan  写道：
>> 
>> 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
>>> 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
>>> func |(_: T.Type, _: U.Type) -> OneOf.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
>>> }
>>> 
>>> // 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.Type, _: OneOf<...U>.Type) -> OneOf.Type {
>>> 
>>> // Copy and merge types into the new `OneOf` type
>>> return OneOf
>>> }
>>> 
>>> 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
>>> typealias ABCD = ABC | D // merging lhs OneOf with D to OneOf
>>> Mission accomplished.
>>> 
>>> 
 在 2016年7月1日，17:06，Cao Jiannan mailto:frog...@163.com>> 
 写道：
 
 https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md
  
 
 
 Hi,
 
 I'm now officially proposal the union type feature for Swift. Please see:
 
 
 https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121
  
 
 Introduction
 
 Add union type grammar, represents the type which is one of other types.
 
 var stringOrURL: String | URL = "https://www.apple.com 
 "
 
 
 I would be thankful if someone support this idea and give some advice. 
 Thanks!
 
 
 --
 Jiannan
 
 
>>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Union Type

[Cao Jiannan via swift-evolution]

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
> 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
> func |(_: T.Type, _: U.Type) -> OneOf.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
> }
> 
> // 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.Type, _: OneOf<...U>.Type) -> OneOf.Type {
> 
> // Copy and merge types into the new `OneOf` type
> return OneOf
> }
> 
> 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
> typealias ABCD = ABC | D // merging lhs OneOf with D to OneOf
> Mission accomplished.
> 
> 
>> 在 2016年7月1日，17:06，Cao Jiannan  写道：
>> 
>> https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md
>>  
>> 
>> 
>> Hi,
>> 
>> I'm now officially proposal the union type feature for Swift. Please see:
>> 
>> 
>> https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121
>>  
>> 
>> Introduction
>> 
>> Add union type grammar, represents the type which is one of other types.
>> 
>> var stringOrURL: String | URL = "https://www.apple.com 
>> "
>> 
>> 
>> I would be thankful if someone support this idea and give some advice. 
>> Thanks!
>> 
>> 
>> --
>> Jiannan
>> 
>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [apple/swift-evolution] Proposal: Union Type

[Cao Jiannan via swift-evolution]

> 下面是被转发的邮件：
> 
> 发件人: Cao Jiannan 
> 主题: 回复： [apple/swift-evolution] Proposal: Union Type (#404)
> 日期: 2016年7月1日 GMT+8 21:22:32
> 收件人: apple/swift-evolution 
> 
> 
> what if OneOf?
> 
> duplicate variable compile warning?
> 
>> 在 2016年7月1日，20:59，Adrian Z. > > 写道：
>> 
>> Just one simple thing to add:
>> 
>> If ...T equals 10 then <...T, U> = 10 + 1 = 11 types
>> If ...U equals 17 then  = 1 + 17 = 18 types
>> If ...T equals 20 and ...Uequals 22 then <...T, ...U> = 20 + 22 = 42 types
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub 
>> , 
>> or mute the thread 
>> .
>> 
> 

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

[swift-evolution] [Proposal] Union Type

[Cao Jiannan via swift-evolution]

Hi all,

I'm now officially proposal the union type feature for Swift. Please see:


https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md
 

Introduction

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

var stringOrURL: String | URL = "https://www.apple.com "


I would be thankful if someone support this idea and give some advice. Thanks!


--
Jiannan

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

[swift-evolution] [Proposal] Union Type

[Cao Jiannan via swift-evolution]

https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md
 


Hi,

I'm now officially proposal the union type feature for Swift. Please see:


https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121 

Introduction

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

var stringOrURL: String | URL = "https://www.apple.com";


I would be thankful if someone support this idea and give some advice. Thanks!


--
Jiannan


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

[swift-evolution] [proposal] Union Type

[Cao Jiannan via swift-evolution]

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 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.
let string: String?
is same to 
let string: (String | None)  instead of let string: 
Optional


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] Union instead of Optional
> 日期: 2016年5月16日 GMT+8 18:35:25
> 收件人: Austin Zheng 
> 抄送: Cao Jiannan , Adrian Zubarev via swift-evolution 
> 
> 
> 
>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution 
>>  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

Re: [swift-evolution] Union instead of Optional

[Cao Jiannan via swift-evolution]

Hi Austin,

let me repeat the example so that clarify my point from this example.

protocol cannot do this:

func input(value: ProtocolForABC) {
print(value.someCommonProperty)

if value is A {

} else if value is B {

} else if value is C {

} else {
// There no other cases, but compiler will not trigger a warning.
}
}

The compiler will not know your protocol is only conformed to these three 
classes.
So the else block will not trigger a warning.

- Jiannan


> 在 2016年5月16日，18:37，Austin Zheng  写道：
> 
> I'm sorry, but I don't understand the point you are trying to make.
> 
> If you pass in a value of type (A | B | C) to a function, what might you want 
> to do with that value?
> 
> If you want to do one thing if the value is type A, something else if the 
> value is type B, and something else if the value is type C, then you need to 
> switch or otherwise type check the value at runtime. You can't get around 
> this, no matter whether you use enums, protocols, generics, or union type.
> 
> If you want it to do something that A, B, and C all support, use a generic 
> and/or a protocol. In this case limiting the inputs to only those three types 
> is probably a design smell. The whole point of a shared interface is that it 
> only matters that the interface is properly implemented by a type, not what 
> that type is.
> 
> If you don't care about doing anything with the value, just make your 
> function generic: func(input: T).
> 
> Austin
> 

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

Re: [swift-evolution] Union instead of Optional

[Cao Jiannan via swift-evolution]

Consider this case:

class A {
var someCommonProperty: Int = 0
}
class B {
var someCommonProperty: Int = 0
}
class C {
var someCommonProperty: Int = 0
}

protocol UnionABC {
var someCommonProperty: Int
}

extension A: UnionABC {}
extension B: UnionABC {}
extension C: UnionABC {}


= If we using protocol


func input(value: UnionABC) {
print(value.someCommonProperty) // Compiler will know their common 
properties automatically.
if value is A {

} else if value is B {

} else if value is C {

} else {
// There are other cases? Compiler doesn't know
}
}

let a = A()
input(a)

= If we using union

func input(value: (A | B | C)) {
print(value.someCommonProperty) // Compiler will know their common 
properties automatically.

if value is A {

} else if value is B {

} else if value is C {

} else {
// There no other cases, so the compiler trigger a warning.
}
}

let a = A()
input(a)


=

If using generic enum,
the compiler doesn’t know the type relation between generic union with original 
type.
class A and UnionOf3 are totally two different types, has no 
relationship.
But class A and (A | B | C) keeps a relationship.

If using union, these two cases will be allowed:

let a = A()
let union: (A|B|C) = a // Automatically wrap.

a == union // Can be compared, Yes

sub-typing: 

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


> 在 2016年5月16日，18:17，Austin Zheng  写道：
> 
> This doesn't explain how I can use 'value' once an A() is passed into the 
> function:
> 
> func input(value: (A | B | C)) {
> 
> }
> 
> 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.
> 
> The other 'gain' is being able to call 'input(A())', rather than 
> 'input(.caseA(A()))'. I agree that the first form is prettier than the second 
> one. I also think you could make the language pervasively prettier and more 
> expressive by allowing for all sorts of implicit conversions. At some point 
> clarity at the point of use beats conciseness, especially when code within a 
> complex codebase needs to be maintained.
> 
> I understand that this is largely a matter of style - different people value 
> different things, and that's wonderful. I welcome a formal proposal submitted 
> to the swift-evolution process, and if one appears I'm happy to consider it 
> in more detail and argue for or against it based on that.
> 
> Austin
> 
> 
> 
> On Sun, May 15, 2016 at 3:34 AM, Cao Jiannan  > wrote:
> for example, there is a method input union of 3 types: A, B, C,
> 
> This is the three class.
> 
> class A {}
> 
> class B {}
> 
> class C {}
> 
> This is how it implemented under Swift 2:
> 
> enum UnionABC {
> case classA(A)
> case classB(B)
> case classC(C)
> }
> 
> func input(value: UnionABC) {
> 
> }
> 
> let a = A()
> let b = B()
> let c = C()
> input(UnionABC.classA(a))
> 
> 
> It needs announce all the cases and name each cases and cannot use class 
> names as their case names.
> 
> what about using union? It is more easy and rational.
> 
> 
> func input(value: (A | B | C)) {
> 
> }
> 
> let a= A()
> input(a)
> 
> Or you can implement it with protocol and extension, but compiler will not 
> know how many cases it should have.
> 
> 
> protocol UnionABC {
> 
> }
> 
> extension A: UnionABC {}
> extension B: UnionABC {}
> extension C: UnionABC {}
> 
> 
> func input(value: UnionABC) {
> if value is A {
> 
> } else if value is B {
> 
> } else if value is C {
> 
> } else {
> // There are other cases? Compiler doesn't know
> }
> }
> 
> let a = A()
> input(a)
> 
> 
> 
>> 下面是被转发的邮件：
>> 
>> 发件人: frog...@163.com 
>> 主题: 回复： [swift-evolution] Union instead of Optional
>> 日期: 2016年5月15日 GMT+8 18:00:55
>> 收件人: Austin Zheng mailto:austinzh...@gmail.com>>
>> 
>> 
>> Enum and Union are two things.
>> 
>> If you use Enum to implement Union, you should announce it with case name.
>> 
>> Another issue using enum instead of union is that,  union can combine types 
>> as many as possible, you just write ( A | B | C ... | Z), but for enum, you 
>> should carefully announce it for each case. 
>> 
>> 在 2016年5月15日，15:22，Austin Zheng > > 写道：
>> 
>>> In addition, not everything in Swift can be modeled in terms of inheritance 
>>> relationships.
>>> 
>>> I'm a little curious as to why union types keep on coming up, when enums 
>>> can do everything they can and much more (methods, constraints on generic 
>>> t

[swift-evolution] [Proposal] Using Union instead of Generic Enum to implement Optional

[Cao Jiannan via swift-evolution]

This is the example implemented with generic and enum.

enum UnionOf3 {
case type0(T)
case type1(U)
case type2(V)
}

func input(value: UnionOf3) {
switch value {
case let .type0(a):
print(a)
case let .type1(b):
print(b)
case let .type2(c):
print(c)
}
}

let a = A()
input(UnionOf3.type0(a))

For each different number N of types to get union, you should announce UnionOfN 
for each.
it is more complicated then the union solution. 

func input(value: (A | B | C)) {
switch value {
case a as A:
print(a)
case b as B:
print(b)
case let .type2(c):
print(c)
}
}

let a= A()
input(a)


And the most bad thing is,
compiler doesn’t know the type relation between generic union with original 
type,
 for example, the type relation between A and A | B and A | B | C.

compare:

enum UnionOf3 {
case type0(T)
case type1(U)
case type2(V)
}

let a = A()
let union: UnionOf3 = UnionOf3.type0(a) // You should wrap by yourself.

a == union // probably the compiler will refuse to compare.

sub-typing: 

var fn0: A->Void = {print($0)}
var fn1: UnionOf2->Void = {print($0)}

fn0 = fn1 // This should be allowed. But will be rejected since using enum.

var fn2: UnionOf3->Void = {print($0)}

fn0 = fn2 // This should be allowed. But will be rejected since using enum.
fn1 = fn2 // This should be allowed. But will be rejected since using enum.


---

If using union, this problem can be solved easily.

let a = A()
let union: (A|B|C) = a // Automatically wrap.

a == union // Yes

sub-typing: 

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

fn0 = fn1 // OK

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

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


> 下面是被转发的邮件：
> 
> 发件人: Cao Jiannan via swift-evolution 
> 主题: [swift-evolution] Fwd: Union instead of Optional
> 日期: 2016年5月15日 GMT+8 18:34:44
> 收件人: Adrian Zubarev via swift-evolution 
> 回复－收件人: Cao Jiannan 
> 
> for example, there is a method input union of 3 types: A, B, C,
> 
> This is the three class.
> 
> class A {}
> 
> class B {}
> 
> class C {}
> 
> This is how it implemented under Swift 2:
> 
> enum UnionABC {
> case classA(A)
> case classB(B)
> case classC(C)
> }
> 
> func input(value: UnionABC) {
> 
> }
> 
> let a = A()
> let b = B()
> let c = C()
> input(UnionABC.classA(a))
> 
> 
> It needs announce all the cases and name each cases and cannot use class 
> names as their case names.
> 
> what about using union? It is more easy and rational.
> 
> 
> func input(value: (A | B | C)) {
> 
> }
> 
> let a= A()
> input(a)
> 
> Or you can implement it with protocol and extension, but compiler will not 
> know how many cases it should have.
> 
> 
> protocol UnionABC {
> 
> }
> 
> extension A: UnionABC {}
> extension B: UnionABC {}
> extension C: UnionABC {}
> 
> 
> func input(value: UnionABC) {
> if value is A {
> 
> } else if value is B {
> 
> } else if value is C {
> 
> } else {
> // There are other cases? Compiler doesn't know
> }
> }
> 
> let a = A()
> input(a)
> 
> 
> 
>> 下面是被转发的邮件：
>> 
>> 发件人: frog...@163.com <mailto:frog...@163.com>
>> 主题: 回复： [swift-evolution] Union instead of Optional
>> 日期: 2016年5月15日 GMT+8 18:00:55
>> 收件人: Austin Zheng mailto:austinzh...@gmail.com>>
>> 
>> 
>> Enum and Union are two things.
>> 
>> If you use Enum to implement Union, you should announce it with case name.
>> 
>> Another issue using enum instead of union is that,  union can combine types 
>> as many as possible, you just write ( A | B | C ... | Z), but for enum, you 
>> should carefully announce it for each case. 
>> 
>> 在 2016年5月15日，15:22，Austin Zheng > <mailto:austinzh...@gmail.com>> 写道：
>> 
>>> In addition, not everything in Swift can be modeled in terms of inheritance 
>>> relationships.
>>> 
>>> I'm a little curious as to why union types keep on coming up, when enums 
>>> can do everything they can and much more (methods, constraints on generic 
>>> types, conformance to protocols).
>>> 
>>> Austin
>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> ___
>>>> swift-evolution mailing list
>>

[swift-evolution] Fwd: Union instead of Optional

[Cao Jiannan via swift-evolution]

for example, there is a method input union of 3 types: A, B, C,

This is the three class.

class A {}

class B {}

class C {}

This is how it implemented under Swift 2:

enum UnionABC {
case classA(A)
case classB(B)
case classC(C)
}

func input(value: UnionABC) {

}

let a = A()
let b = B()
let c = C()
input(UnionABC.classA(a))


It needs announce all the cases and name each cases and cannot use class names 
as their case names.

what about using union? It is more easy and rational.


func input(value: (A | B | C)) {

}

let a= A()
input(a)

Or you can implement it with protocol and extension, but compiler will not know 
how many cases it should have.


protocol UnionABC {

}

extension A: UnionABC {}
extension B: UnionABC {}
extension C: UnionABC {}


func input(value: UnionABC) {
if value is A {

} else if value is B {

} else if value is C {

} else {
// There are other cases? Compiler doesn't know
}
}

let a = A()
input(a)



> 下面是被转发的邮件：
> 
> 发件人: frog...@163.com
> 主题: 回复： [swift-evolution] Union instead of Optional
> 日期: 2016年5月15日 GMT+8 18:00:55
> 收件人: Austin Zheng 
> 
> 
> Enum and Union are two things.
> 
> If you use Enum to implement Union, you should announce it with case name.
> 
> Another issue using enum instead of union is that,  union can combine types 
> as many as possible, you just write ( A | B | C ... | Z), but for enum, you 
> should carefully announce it for each case. 
> 
> 在 2016年5月15日，15:22，Austin Zheng  > 写道：
> 
>> In addition, not everything in Swift can be modeled in terms of inheritance 
>> relationships.
>> 
>> I'm a little curious as to why union types keep on coming up, when enums can 
>> do everything they can and much more (methods, constraints on generic types, 
>> conformance to protocols).
>> 
>> Austin
 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 
>>> 

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

Re: [swift-evolution] Union instead of Optional

[Cao, Jiannan via swift-evolution]

Optional should be implement by union concept s instead of using generic.

Enum cannot be easily used to represent many types until you name all of them. 

Both generic and enum solution cannot build a strong relation between optional 
type and its original type, for example, an Integer type has no reparation with 
Optional, until the compiler make a special case for Optional to 
automatically unwrap or wrap for this.

> 在 2016年5月15日，15:19，David Hart  写道：
> 
> Enums with associated types in Swift are the equivalent of unions, even if 
> they don’t have the name. I don’t see what your proposal is trying to solve?
> 
>> On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution 
>>  wrote:
>> 
>> 
>> It’s kind of same idea of TypeScipt 2, at 46:21 in this video.
>> 
>> https://channel9.msdn.com/Events/Build/2016/B881
>> 
>> <屏幕快照 2016-05-15 10.20.36.png>
>> 
>> 
>>> 
>>> 2016-2-16 GMT+8 14:36:28
>>> Hi all,
>>> 
>>> I think the best way to solve the either problem is to separate it from 
>>> generic. 
>>> Optional and Either shouldn’t work the same way of generic type. 
>>> It’s just a represent of multiple type in one location.
>>> 
>>> Using an old friend, Union in C.
>>> union {
>>> case firstType
>>> case secondType
>>> }
>>> 
>>> This is the final solution for the sub typing problem of optional.
>>> 
>>> A  == union(A,A)
>>> union(A,B) == union(B,A)
>>> B == union(B,B)
>>> 
>>> B is subtype of union(A,B)
>>> A is subtype of union(A,B)
>>> union(A,B,C) is subtype of union(A,B,C,D,…)
>>> 
>>> suppose 
>>> a is subclass of A
>>> b is subclass of B, then
>>> union(a,B) is subtype of union(A,B)
>>> union(A,b) is subtype of union(A,B)
>>> union(a,b) is subtype of union(a,B)
>>> union(a,b) is subtype of union(A,b)
>>> 
>>> union can have as many case as possible. e.g., union(A,B,C,D,…)
>>> 
>>> So the Optional should be union(UITableView, None)
>>> and Optional should be union(MyTableView, None), which is 
>>> subclass of union(UITableView, None)
>>> 
>>> This is a final rational solution. I think.
>>> 
>>> -Jiannan
>> 
>> 
>> 
>> 
>> ___
>> 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

[swift-evolution] IUO type, treat nil as normal error, not fatal error

[Cao Jiannan via swift-evolution]

Hi all,

I want to discuss the Implicitly Unwrapped Optional Type.

In Swift 1 and Swift2, when a variable declared as IUO type, its value should 
be non-nil. 
If its value is nil, it will crash the program when read the value.

I  believe it is better to let developer catch this event, treat it as normal 
error, and can be caught.

Thanks!

Jiannan




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