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 
>> > 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] What're the Swift team's thoughts on Go's concurrency?

[Chris Lattner via swift-evolution]

> On Aug 9, 2016, at 12:04 PM, Dan Stenmark via swift-evolution 
>  wrote:
> 
> I'd like to inquire as to what the Swift team thoughts on Go's concurrency 
> model are?  I'm not referring to convenience of the 'go' keyword and nor am I 
> referring to how the language handles Channels, both of which being what most 
> folks associate with it.  Rather, I'd like to ask about the language's use of 
> Green Threads and how the runtime handles the heavy lifting of multiplexing 
> and scheduling them.  What are some of the strengths and weaknesses the Swift 
> team sees to Go's approach?

Hi Dan,

There are many folks interested in concurrency topics related to this, but we 
need to stay focused on finishing Swift 3 and then moving on to Swift 4 stage 1 
goals.  As that work is cresting, we’ll start discussions of concurrency, and 
may even be so bold as to start a new mailing list dedicated to the topic, 
since it is such a wide reaching topic.

Until we get to that point, please resist the urge to jump ahead :-)

-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

[Chris Lattner via swift-evolution]

> 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

[Charlie Monroe via swift-evolution]

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 
>  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 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 
>> 
>> 
>> 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 
>> > 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" > > 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 
>> > 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.
>>> 
>>> 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] [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 
> 
> 
> 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 
> > 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"  > 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 
> > 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.
>> 
>> 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 
>> 
> 
> 
>  
> ___
> 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]

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

[Xiaodi Wu via swift-evolution]

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> 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"  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/-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
>
>
>
>
> ___
> 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]

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

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

[Step C via swift-evolution]

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 
>  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.
> 
> 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
___
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] [Late Pitch] Deprecations, Moves, and Renames

[Brent Royal-Gordon via swift-evolution]

> On Aug 9, 2016, at 12:09 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> Deprecate the Indexable protocols with a message indicating that they
>  will be gone in Swift 4.

Should IndexableBase get the same treatment? Or is that hidden anyway?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Dmitri Gribenko via swift-evolution]

On Wed, Aug 10, 2016 at 3:50 PM, David Sweeris via swift-evolution
 wrote:
> For example, maybe you really do need to interpret a 64-bit chunk of data as 
> an Int64, even though the compiler is convinced it’s a Double. We can do that 
> in Swift through the various “unsafe” functions, which is where they belong 
> because 99.99% of the time that’s a bad idea.

"42.0.bitPattern".  Why do you think this conversion is unsafe?

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swiftier implementation of Measurement and Unit

[Dave Abrahams via swift-evolution]

on Wed Aug 10 2016, Joanna Carter  wrote:

> I have spent some time working on a version of the Measurement and
> Unit held in the apple/swift-corelibs-foundation section of
> GitHub. How can I best find out if my efforts are worthwhile?

I'm not sure how useful this is, because it's not really a comment on
your efforts, but... some of us think we know how this problem domain
*should* be addressed, and we know that Swift doesn't yet have the
necessary language facilities (integer generic parameters) to do the job
right.  The technique was described back in 1994 by Barton & Nackman in
https://www.amazon.com/Scientific-Engineering-Introduction-Advanced-Techniques/dp/0201533936

HTH,
-- 
-Dave

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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[David Sweeris via swift-evolution]

> On Aug 10, 2016, at 5:36 PM, Slava Pestov  wrote:
> 
> 
>> On Aug 10, 2016, at 3:34 PM, Christopher Kornher  wrote:
>> 
>> Would this prevent an object from being “known" to multiple threads? 
>> …multiple queues? If so, it would be overly restrictive for a 
>> general-purpose language. I assume that the plan includes a way to allow 
>> “unsafe” behavior to support other concurrency models.
>> 
> 
> To be clear I'm not presenting any ideas for Swift here, just critiquing Go's 
> model.
> 
> Yes, I'm just talking about 'safe' language features for passing immutable 
> data between threads. This would not preclude other forms of concurrency from 
> existing in the language, such as locks, atomics, etc. But I think if a user 
> writes code with only message passing, the language should ensure that the 
> result is free from data races. Go does not do that, which is unfortunate.
> 
Oh, *that* I’ll agree with… I was just talking about situations where there is 
no “safe” way to do it (for whatever your language’s/compiler’s idea of “safe” 
is). For example, maybe you really do need to interpret a 64-bit chunk of data 
as an Int64, even though the compiler is convinced it’s a Double. We can do 
that in Swift through the various “unsafe” functions, which is where they 
belong because 99.99% of the time that’s a bad idea. That 0.01% though…

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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Slava Pestov via swift-evolution]

> On Aug 10, 2016, at 3:34 PM, Christopher Kornher  wrote:
> 
> Would this prevent an object from being “known" to multiple threads? 
> …multiple queues? If so, it would be overly restrictive for a general-purpose 
> language. I assume that the plan includes a way to allow “unsafe” behavior to 
> support other concurrency models.
> 

To be clear I'm not presenting any ideas for Swift here, just critiquing Go's 
model.

Yes, I'm just talking about 'safe' language features for passing immutable data 
between threads. This would not preclude other forms of concurrency from 
existing in the language, such as locks, atomics, etc. But I think if a user 
writes code with only message passing, the language should ensure that the 
result is free from data races. Go does not do that, which is unfortunate.

Slava

> 
>> On Aug 10, 2016, at 4:24 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Aug 10, 2016, at 3:22 PM, David Sweeris  wrote:
>>> 
 On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
  wrote:
 
 As I understand it, a big weakness of Go's model is that it does not 
 actually prevent data races. There's nothing preventing you from sharing 
 pointers to mutable values between tasks, but I could be wrong about this.
>>> Is that bad? Sharing pointers seems like a cheap way to share data, and as 
>>> long as you know what you’re doing, why should the language get in the way? 
>>> Now, if said code really does have performance advantages over the “safer” 
>>> methods, and it really is safe because for whatever reason the race 
>>> condition can’t actually happen, the language (or library) ought to have a 
>>> way to express that without having to write “unsafe” code. In the meantime, 
>>> though, you’ve gotta ship something that runs and meets performance 
>>> requirements.
>> 
>> Well, ideally, the type system would be able to enforce that values passed 
>> across thread boundaries are immutable. Rust's model allows this, I believe.
>> 
>> The possibility of mutating shared state in an unprincipled manner is "bad" 
>> in the same sense that being able to call free() in C is "bad" -- it's an 
>> abstraction violation if you get it wrong. Compared to languages with 
>> automatic memory management, there are advantages (control over memory 
>> management) and disadvantages (fewer static guarantees).
>> 
>> 
>>> 
>>> - Dave Sweeris
>> 
>> ___
>> 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] Swiftier implementation of Measurement and Unit

[Joanna Carter via swift-evolution]

I have spent some time working on a version of the Measurement and Unit 
held in the apple/swift-corelibs-foundation section of GitHub. How can I 
best find out if my efforts are worthwhile?


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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Christopher Kornher via swift-evolution]

Would this prevent an object from being “known" to multiple threads? …multiple 
queues? If so, it would be overly restrictive for a general-purpose language. I 
assume that the plan includes a way to allow “unsafe” behavior to support other 
concurrency models.


> On Aug 10, 2016, at 4:24 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Aug 10, 2016, at 3:22 PM, David Sweeris  wrote:
>> 
>>> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> As I understand it, a big weakness of Go's model is that it does not 
>>> actually prevent data races. There's nothing preventing you from sharing 
>>> pointers to mutable values between tasks, but I could be wrong about this.
>> Is that bad? Sharing pointers seems like a cheap way to share data, and as 
>> long as you know what you’re doing, why should the language get in the way? 
>> Now, if said code really does have performance advantages over the “safer” 
>> methods, and it really is safe because for whatever reason the race 
>> condition can’t actually happen, the language (or library) ought to have a 
>> way to express that without having to write “unsafe” code. In the meantime, 
>> though, you’ve gotta ship something that runs and meets performance 
>> requirements.
> 
> Well, ideally, the type system would be able to enforce that values passed 
> across thread boundaries are immutable. Rust's model allows this, I believe.
> 
> The possibility of mutating shared state in an unprincipled manner is "bad" 
> in the same sense that being able to call free() in C is "bad" -- it's an 
> abstraction violation if you get it wrong. Compared to languages with 
> automatic memory management, there are advantages (control over memory 
> management) and disadvantages (fewer static guarantees).
> 
> 
>> 
>> - Dave Sweeris
> 
> ___
> 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] [Pitch] Rename Mirror

[Anton Zhilin via swift-evolution]

2016-08-11 0:40 GMT+03:00 Slava Pestov :
>
> I think pointing a Mirror at a metatype value could be a good a mechanism
> for getting information about the type's stored properties and other
> members.
>
> FWIW Mirrors are inspired by a feature of the same name in the Self
> language, which made reflection somewhat more principled than the
> disorganized APIs you see in Java and C#. Perhaps the latter are not a good
> model to follow here :-)
>

Swift and Self lie in different families of languages.
In Self (and Smalltalk, and ObjC), types don't really matter: one can
modify methods, which some object has, independently of all other objects.
Because of this dynamism, reflection of types has little value in these
languages.

On the other hand, in Swift (and C++, and Java) types do matter. It is
useful to get, for example, a Method, and be sure that you can call it on
all instances of matching type.
I think that Swift should favor types and not instances, as it
unfortunately does today.

This is how I imagine reflection API. We have a type ID and can request
different information about it. For example:  func getMethod(name: String)
-> Method?
Most importantly, we should be able to get IDs of other related types, and
related type IDs of theirs, and so on, without collecting excessive data.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 10 Aug 2016, at 22:44, Erica Sadun wrote:
> 
>> On Aug 9, 2016, at 1:09 PM, Dave Abrahams wrote:
>> 
>> Hi Everybody,
>> 
>> With another round of apologies for taking late action, we propose to
>> make some deprecations, moves, and renames.  The background for these
>> moves is as follows:
>> 
>> We've always known that when Swift reached ABI stability (now slated for
>> Swift 4), we would be committed to supporting many of the standard
>> library's design decisions for years to come.  What we only realized
>> very recently is that, although Swift 3.0 is *not* shipping with a
>> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
>> code creates similar implications when it comes to certain protocols,
>> today.  Especially where these protocols show up in refinement
>> hierarchies, we can't keep Swift 3 code working in the future without
>> carrying them forward into future libraries.
>> 
>> The proposed changes are as follows:
>> 
>> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>> This component is really only useful for playgrounds, and doesn't
>> belong in the standard library.
> 
> This seems like an obvious win. I *strongly* support this. (Didn't we discuss 
> this
> several weeks ago?)

Yes, we did:



But that part of the proposal has been withdrawn:



> Since you've opened the doors to last minute discussions, I also feel quite 
> strongly
> that image/color/file literals are misplaced and do not belong as part of the 
> standard library. The image one is the best example of the misfit. Images 
> will probably 
> never be a core component of stdlib but they don't fit in PlaygroundSupport 
> either as they 
> are essentially EditorSupport-ive. They have value across multiple platforms 
> (currently
> OS X and the UIKit family, but primarily act in an Xcode-support role) but 
> could be extended
> to other editors and other platforms. (And yes, I have list of other items 
> but they fall well
> outside the scope of the current Swift Ev discussion so I'm sitting on them.)
> 
>> * Deprecate the Indexable protocols with a message indicating that they
>> will be gone in Swift 4.  These protocols are implementation details
>> of the standard library designed to work around language limitations
>> that we expect to be gone in Swift 4.  There's no reason for anyone to
>> ever touch these; users should always use a corresponding Collection
>> protocol (e.g. instead of MutableIndexable, use MutableCollection).
> 
> It's time to for indices to evolve. 
> 
>> * Deprecate the ExpressibleByStringInterpolation protocol with a
>> message indicating that its design is expected to change.  We know
>> this protocol to be mis-designed
>> (https://bugs.swift.org/browse/SR-1260) and limited
>> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>> for Swift 3.  If we knew what the new design should look like, we
>> might be able to calculate that the current API is supportable in a
>> forward-compatible way (as we do for Comparable).  Unfortunately, we
>> do not.
> 
> I'm glad you're thinking forward about this.
> 
>> * Rename Streamable to TextOutputStreamable and add a deprecated
>> Streamable typealias for it.  Now that OutputStream been renamed to
>> TextOutputStream, we should also move Streamable out of the way.
> 
> Fine. Now if only I could figure out how to get this working. Been
> banging my head against the new streaming stuff. Also it shouldn't be
> this hard to print(toStream: CustomCustomCustomBlah.stderr)

See the LocalFileOutputByteStream class and the `<<<` operator in:



>> Deprecation is being proposed instead of underscoring or renaming
>> because it allows existing code to keep working (with warnings).  At
>> this late stage, it would be bad to actually break anything.
> 
> Sensible.
> 
> -- E

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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Slava Pestov via swift-evolution]

> On Aug 10, 2016, at 3:22 PM, David Sweeris  wrote:
> 
>> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> As I understand it, a big weakness of Go's model is that it does not 
>> actually prevent data races. There's nothing preventing you from sharing 
>> pointers to mutable values between tasks, but I could be wrong about this.
> Is that bad? Sharing pointers seems like a cheap way to share data, and as 
> long as you know what you’re doing, why should the language get in the way? 
> Now, if said code really does have performance advantages over the “safer” 
> methods, and it really is safe because for whatever reason the race condition 
> can’t actually happen, the language (or library) ought to have a way to 
> express that without having to write “unsafe” code. In the meantime, though, 
> you’ve gotta ship something that runs and meets performance requirements.

Well, ideally, the type system would be able to enforce that values passed 
across thread boundaries are immutable. Rust's model allows this, I believe.

The possibility of mutating shared state in an unprincipled manner is "bad" in 
the same sense that being able to call free() in C is "bad" -- it's an 
abstraction violation if you get it wrong. Compared to languages with automatic 
memory management, there are advantages (control over memory management) and 
disadvantages (fewer static guarantees).


> 
> - Dave Sweeris

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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[David Sweeris via swift-evolution]

> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> As I understand it, a big weakness of Go's model is that it does not actually 
> prevent data races. There's nothing preventing you from sharing pointers to 
> mutable values between tasks, but I could be wrong about this.
Is that bad? Sharing pointers seems like a cheap way to share data, and as long 
as you know what you’re doing, why should the language get in the way? Now, if 
said code really does have performance advantages over the “safer” methods, and 
it really is safe because for whatever reason the race condition can’t actually 
happen, the language (or library) ought to have a way to express that without 
having to write “unsafe” code. In the meantime, though, you’ve gotta ship 
something that runs and meets performance requirements.

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Erica Sadun via swift-evolution]

> On Aug 9, 2016, at 1:09 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> Hi Everybody,
> 
> With another round of apologies for taking late action, we propose to
> make some deprecations, moves, and renames.  The background for these
> moves is as follows:
> 
> We've always known that when Swift reached ABI stability (now slated for
> Swift 4), we would be committed to supporting many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
> 
> The proposed changes are as follows:
> 
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>  This component is really only useful for playgrounds, and doesn't
>  belong in the standard library.

This seems like an obvious win. I *strongly* support this. (Didn't we discuss 
this
several weeks ago?)

Since you've opened the doors to last minute discussions, I also feel quite 
strongly
that image/color/file literals are misplaced and do not belong as part of the 
standard library. The image one is the best example of the misfit. Images will 
probably 
never be a core component of stdlib but they don't fit in PlaygroundSupport 
either as they 
are essentially EditorSupport-ive. They have value across multiple platforms 
(currently
OS X and the UIKit family, but primarily act in an Xcode-support role) but 
could be extended
to other editors and other platforms. (And yes, I have list of other items but 
they fall well
outside the scope of the current Swift Ev discussion so I'm sitting on them.)

> * Deprecate the Indexable protocols with a message indicating that they
>  will be gone in Swift 4.  These protocols are implementation details
>  of the standard library designed to work around language limitations
>  that we expect to be gone in Swift 4.  There's no reason for anyone to
>  ever touch these; users should always use a corresponding Collection
>  protocol (e.g. instead of MutableIndexable, use MutableCollection).

It's time to for indices to evolve. 

> * Deprecate the ExpressibleByStringInterpolation protocol with a
>  message indicating that its design is expected to change.  We know
>  this protocol to be mis-designed
>  (https://bugs.swift.org/browse/SR-1260) and limited
>  (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>  for Swift 3.  If we knew what the new design should look like, we
>  might be able to calculate that the current API is supportable in a
>  forward-compatible way (as we do for Comparable).  Unfortunately, we
>  do not.

I'm glad you're thinking forward about this.

> * Rename Streamable to TextOutputStreamable and add a deprecated
>  Streamable typealias for it.  Now that OutputStream been renamed to
>  TextOutputStream, we should also move Streamable out of the way.

Fine. Now if only I could figure out how to get this working. Been
banging my head against the new streaming stuff. Also it shouldn't be
this hard to print(toStream: CustomCustomCustomBlah.stderr)

> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.

Sensible.

-- E

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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Slava Pestov via swift-evolution]

> On Aug 9, 2016, at 1:59 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution 
>>  wrote:
>> 
>> The Rust language used to use a green thread model like Go (actually it 
>> exposed a configurable threading interface so you could choose green threads 
>> or OS threads). It also used segmented stacks like Go did. Over time, Rust 
>> ended up dropping the segmented stacks because it significantly complicated 
>> FFI without providing much, if any, benefit (and IIRC Go followed suite and 
>> dropped segmented stacks somewhere around version 1.5), and then a little 
>> while later Rust dropped green threads entirely. If you can find them, there 
>> are lots of discussions of the pros and cons that were documented during 
>> this process (on mailing lists, in IRC, possibly on Discourse, there's 
>> probably at least one post about it in the Rust subreddit, etc). But 
>> ultimately, it was determined that keeping this ability significantly 
>> complicated the Rust runtime and it provided almost no benefit. The OS is 
>> already really good at scheduling threads, and there's no memory savings 
>> without segmented stacks (though the OS will map virtual pages for the stack 
>> and only allocate the backing physical pages as the memory is touched, so 
>> even if you have a 2MB stack, a new thread will only actually allocate 
>> something like 8kb). And there are some pretty big downsides to green 
>> threads, such as the fact that it significantly complicates the runtime 
>> since all I/O everywhere has to be nonblocking and it has to be transparent 
>> to the code, and FFI ends up as a major problem (even without segmented 
>> stacks), because you have no idea if an FFI call will block. Green threading 
>> libraries end up having to allocate extra OS threads just to continue 
>> servicing the green threads when the existing threads are potentially 
>> blocked in FFI.
>> 
>> So ultimately, green threads really only make sense when you control the 
>> entire ecosystem, so you can ensure the whole stack is compatible with green 
>> threads and won't ever issue blocking calls, and even there there's not much 
>> benefit and there's a lot of complexity involved.
> 
> In addition to FFI, there's also no way for memory-mapped IO to be 
> non-blocking (a page fault can only be handled by the kernel, after all).

Even buffered file I/O via read(2) and write(2) is blocking on most *nix 
platforms. AFAIK there's some work being done on non-blocking buffered reads on 
Linux, but it appears to be a completely new API distinct from the existing 
epoll for sockets or aio_* for direct file I/O, and of course Darwin doesn't 
have an equivalent.

Slava

> 
> -Joe
> ___
> 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] [Pitch] Rename Mirror

[Slava Pestov via swift-evolution]

> On Jul 21, 2016, at 4:06 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko  >:
> > Mirror.DisplayStyle contains optional and set as special cases, but does not
> > contain function
> > Mirror collects all information possible at initialization, while for true
> > reflection we want laziness
> > Mirror allows customization. For example, Array is represented with a
> > field for each of its elements. Do we want this for “true” reflection we
> > want to add in the future?
> 
> Why can't we add these features to Mirror in future?
> 
> Reflection in some other languages works as follows: we have a type (let's 
> name it 'Reflection'). Each instance of it contains ID of one type and can, 
> for example, retrieve an array of its static or normal methods.
> 'Mirror', on the other hand, serves as a container for information about a 
> single instance. Moreover, types can completely customize contents of their 
> 'Mirror's. This is incompatible with laziness and with how reflection should 
> work, based on experience from other languages.

I think pointing a Mirror at a metatype value could be a good a mechanism for 
getting information about the type's stored properties and other members.

FWIW Mirrors are inspired by a feature of the same name in the Self language, 
which made reflection somewhat more principled than the disorganized APIs you 
see in Java and C#. Perhaps the latter are not a good model to follow here :-)

Slava


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

Re: [swift-evolution] [Review] SE-0137: Avoiding Lock-In to Legacy Protocol Designs

[John McCall via swift-evolution]

> On Aug 10, 2016, at 2:03 PM, John McCall via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0137: Avoiding Lock-In to Legacy Protocol Designs" begins 
> now and runs through August 14. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.md
>  
> 

I'm sorry, this link is incorrect.  The right link is:

  
https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.md
 


John.

> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> John McCall
> 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] [Review] SE-0137: Avoiding Lock-In to Legacy Protocol Designs

[John McCall via swift-evolution]

Hello Swift community,

The review of "SE-0137: Avoiding Lock-In to Legacy Protocol Designs" begins now 
and runs through August 14. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.md
 


Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 


or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

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


Thank you,

John McCall
Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 10 Aug 2016, at 17:24, Dave Abrahams wrote:
> 
>> on Wed Aug 10 2016, Ben Rimmington wrote:
>> 
>> In apple/swift#4131, these lines have overrun the 80 column limit:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> TextFormatting.rst also needs `Streamable` => `TextOutputStreamable`:
>> 
>> 
> 
> Pull requests gratefully accepted for all of these corrections




-- Ben

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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Tim Vermeulen via swift-evolution]

Some protocols of SE-0104 seem to be part of the latest Swift 3 snapshots 
(Arithmetic, FixedWidthInteger, etc) - was this a mistake then, if they won’t 
be in Swift 3.0?

> on Wed Aug 10 2016, Ben Rimmingtonwrote:
> 
> > > On 10 Aug 2016, at 00:36, Dave Abrahams wrote:
> > > 
> > > > on Tue Aug 09 2016, Ben Rimmington wrote:
> > > > 
> > > > > On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
> > 
> > > > > 
> > > > > Hi Everybody,
> > > > > 
> > > > > With another round of apologies for taking late action, we propose to
> > > > > make some deprecations, moves, and renames. The background for these
> > > > > moves is as follows:
> > > > > 
> > > > > We've always known that when Swift reached ABI stability (now slated 
> > > > > for
> > > > > Swift 4), we would be committed to supporting many of the standard
> > > > > library's design decisions for years to come. What we only realized
> > > > > very recently is that, although Swift 3.0 is *not* shipping with a
> > > > > stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> > > > > code creates similar implications when it comes to certain protocols,
> > > > > today. Especially where these protocols show up in refinement
> > > > > hierarchies, we can't keep Swift 3 code working in the future without
> > > > > carrying them forward into future libraries.
> > > > > 
> > > > > The proposed changes are as follows:
> > > > > 
> > > > > * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport 
> > > > > module.
> > > > > This component is really only useful for playgrounds, and doesn't
> > > > > belong in the standard library.
> > > > 
> > > > I didn't think it was possible to `import PlaygroundSupport` unless the
> > > > current file is within a playground. If so, how can corelibs-foundation
> > > > or third-party modules add `CustomPlaygroundQuickLookable`
> > > > conformance?
> > > 
> > > Ahhh... yeah, I didn't realize that, and we don't have time to change
> > > that restriction for Swift 3. It's not a problem for
> > > corelibs-foundation but it would be for 3rd-party libraries.
> > > 
> > > OK, Dmitri and I just figured out how we can change the home of these
> > > types for Swift 4 without breaking Swift 3 code (mirrors to the rescue!)
> > > So I'm going to withdraw this part of the proposal.
> > 
> > Will the following need to be reverted?
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> Technically, no, because typealiases make it unnecessary, but yes, we
> plan to do that.
> 
> > > > > * Deprecate the Indexable protocols with a message indicating that 
> > > > > they
> > > > > will be gone in Swift 4. These protocols are implementation details
> > > > > of the standard library designed to work around language limitations
> > > > > that we expect to be gone in Swift 4. There's no reason for anyone to
> > > > > ever touch these; users should always use a corresponding Collection
> > > > > protocol (e.g. instead of MutableIndexable, use MutableCollection).
> > > > > 
> > > > > * Deprecate the ExpressibleByStringInterpolation protocol with a
> > > > > message indicating that its design is expected to change. We know
> > > > > this protocol to be mis-designed
> > > > > (https://bugs.swift.org/browse/SR-1260) and limited
> > > > > (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
> > > > > for Swift 3. If we knew what the new design should look like, we
> > > > > might be able to calculate that the current API is supportable in a
> > > > > forward-compatible way (as we do for Comparable). Unfortunately, we
> > > > > do not.
> > > > > 
> > > > > * Rename Streamable to TextOutputStreamable and add a deprecated
> > > > > Streamable typealias for it. Now that OutputStream been renamed to
> > > > > TextOutputStream, we should also move Streamable out of the way.
> > 
> > In apple/swift#4131, these lines have overrun the 80 column limit:
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > TextFormatting.rst also needs `Streamable` =>`TextOutputStreamable`:
> > 
> > 
> Pull requests gratefully accepted for all of these corrections
> 
> > > > > Deprecation is being proposed instead of underscoring or renaming
> > > > > because it allows existing code to keep 

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Dave Abrahams via swift-evolution]

on Wed Aug 10 2016, Dave Abrahams  wrote:

> on Wed Aug 10 2016, Ben Rimmington  wrote:
>
>>> On 10 Aug 2016, at 00:36, Dave Abrahams wrote:
>>> 
 on Tue Aug 09 2016, Ben Rimmington wrote:
 
> On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
>>
> 
> Hi Everybody,
> 
> With another round of apologies for taking late action, we propose to
> make some deprecations, moves, and renames.  The background for these
> moves is as follows:
> 
> We've always known that when Swift reached ABI stability (now slated for
> Swift 4), we would be committed to supporting many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
> 
> The proposed changes are as follows:
> 
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
> This component is really only useful for playgrounds, and doesn't
> belong in the standard library.
 
 I didn't think it was possible to `import PlaygroundSupport` unless the 
 current file is within a playground. If so, how can corelibs-foundation 
 or third-party modules add `CustomPlaygroundQuickLookable`
 conformance?
>>> 
>>> Ahhh... yeah, I didn't realize that, and we don't have time to change
>>> that restriction for Swift 3.  It's not a problem for
>>> corelibs-foundation but it would be for 3rd-party libraries.  
>>> 
>>> OK, Dmitri and I just figured out how we can change the home of these
>>> types for Swift 4 without breaking Swift 3 code (mirrors to the rescue!)
>>> So I'm going to withdraw this part of the proposal.
>>
>> Will the following need to be reverted?
>>
>> 
>>
>> 
>> 
>> 
>> 
>> 
>
> Technically, no, because typealiases make it unnecessary, but yes, we
> plan to do that.

done: 
https://github.com/apple/swift-xcode-playground-support/commit/0f42ade5a6302cf953a3ed32a892f23e8e150c62

> * Deprecate the Indexable protocols with a message indicating that they
> will be gone in Swift 4.  These protocols are implementation details
> of the standard library designed to work around language limitations
> that we expect to be gone in Swift 4.  There's no reason for anyone to
> ever touch these; users should always use a corresponding Collection
> protocol (e.g. instead of MutableIndexable, use MutableCollection).
> 
> * Deprecate the ExpressibleByStringInterpolation protocol with a
> message indicating that its design is expected to change.  We know
> this protocol to be mis-designed
> (https://bugs.swift.org/browse/SR-1260) and limited
> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
> for Swift 3.  If we knew what the new design should look like, we
> might be able to calculate that the current API is supportable in a
> forward-compatible way (as we do for Comparable).  Unfortunately, we
> do not.
> 
> * Rename Streamable to TextOutputStreamable and add a deprecated
> Streamable typealias for it.  Now that OutputStream been renamed to
> TextOutputStream, we should also move Streamable out of the way.
>>
>> In apple/swift#4131, these lines have overrun the 80 column limit:
>>
>> 
>> 
>>
>> 
>> 
>>
>> TextFormatting.rst also needs `Streamable` => `TextOutputStreamable`:
>>
>> 
>
> Pull requests gratefully accepted for all of these corrections
>
> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.
 
 If the SE-0104 (protocol-oriented integers) proposal has been deferred, 
 should any protocols (e.g. SignedNumber) be deprecated?
>>
>> Will the SE-0104 

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Dave Abrahams via swift-evolution]

on Wed Aug 10 2016, Ben Rimmington  wrote:

>> On 10 Aug 2016, at 00:36, Dave Abrahams wrote:
>> 
>>> on Tue Aug 09 2016, Ben Rimmington wrote:
>>> 
 On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
>
 
 Hi Everybody,
 
 With another round of apologies for taking late action, we propose to
 make some deprecations, moves, and renames.  The background for these
 moves is as follows:
 
 We've always known that when Swift reached ABI stability (now slated for
 Swift 4), we would be committed to supporting many of the standard
 library's design decisions for years to come.  What we only realized
 very recently is that, although Swift 3.0 is *not* shipping with a
 stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
 code creates similar implications when it comes to certain protocols,
 today.  Especially where these protocols show up in refinement
 hierarchies, we can't keep Swift 3 code working in the future without
 carrying them forward into future libraries.
 
 The proposed changes are as follows:
 
 * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
 This component is really only useful for playgrounds, and doesn't
 belong in the standard library.
>>> 
>>> I didn't think it was possible to `import PlaygroundSupport` unless the 
>>> current file is within a playground. If so, how can corelibs-foundation 
>>> or third-party modules add `CustomPlaygroundQuickLookable`
>>> conformance?
>> 
>> Ahhh... yeah, I didn't realize that, and we don't have time to change
>> that restriction for Swift 3.  It's not a problem for
>> corelibs-foundation but it would be for 3rd-party libraries.  
>> 
>> OK, Dmitri and I just figured out how we can change the home of these
>> types for Swift 4 without breaking Swift 3 code (mirrors to the rescue!)
>> So I'm going to withdraw this part of the proposal.
>
> Will the following need to be reverted?
>
> 
>
> 
> 
> 
> 
> 

Technically, no, because typealiases make it unnecessary, but yes, we
plan to do that.

 * Deprecate the Indexable protocols with a message indicating that they
 will be gone in Swift 4.  These protocols are implementation details
 of the standard library designed to work around language limitations
 that we expect to be gone in Swift 4.  There's no reason for anyone to
 ever touch these; users should always use a corresponding Collection
 protocol (e.g. instead of MutableIndexable, use MutableCollection).
 
 * Deprecate the ExpressibleByStringInterpolation protocol with a
 message indicating that its design is expected to change.  We know
 this protocol to be mis-designed
 (https://bugs.swift.org/browse/SR-1260) and limited
 (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
 for Swift 3.  If we knew what the new design should look like, we
 might be able to calculate that the current API is supportable in a
 forward-compatible way (as we do for Comparable).  Unfortunately, we
 do not.
 
 * Rename Streamable to TextOutputStreamable and add a deprecated
 Streamable typealias for it.  Now that OutputStream been renamed to
 TextOutputStream, we should also move Streamable out of the way.
>
> In apple/swift#4131, these lines have overrun the 80 column limit:
>
> 
> 
>
> 
> 
>
> TextFormatting.rst also needs `Streamable` => `TextOutputStreamable`:
>
> 

Pull requests gratefully accepted for all of these corrections

 Deprecation is being proposed instead of underscoring or renaming
 because it allows existing code to keep working (with warnings).  At
 this late stage, it would be bad to actually break anything.
>>> 
>>> If the SE-0104 (protocol-oriented integers) proposal has been deferred, 
>>> should any protocols (e.g. SignedNumber) be deprecated?
>
> Will the SE-0104 proposal be accepted for Swift 4.0?

It is expected to be.  We may even be able to get it into a Swift 3
point-release (e.g. 3.1)

-- 
Dave
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 10 Aug 2016, at 00:36, Dave Abrahams wrote:
> 
>> on Tue Aug 09 2016, Ben Rimmington wrote:
>> 
>>> On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
>>> 
>>> Hi Everybody,
>>> 
>>> With another round of apologies for taking late action, we propose to
>>> make some deprecations, moves, and renames.  The background for these
>>> moves is as follows:
>>> 
>>> We've always known that when Swift reached ABI stability (now slated for
>>> Swift 4), we would be committed to supporting many of the standard
>>> library's design decisions for years to come.  What we only realized
>>> very recently is that, although Swift 3.0 is *not* shipping with a
>>> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
>>> code creates similar implications when it comes to certain protocols,
>>> today.  Especially where these protocols show up in refinement
>>> hierarchies, we can't keep Swift 3 code working in the future without
>>> carrying them forward into future libraries.
>>> 
>>> The proposed changes are as follows:
>>> 
>>> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>>> This component is really only useful for playgrounds, and doesn't
>>> belong in the standard library.
>> 
>> I didn't think it was possible to `import PlaygroundSupport` unless the 
>> current file is within a playground. If so, how can corelibs-foundation 
>> or third-party modules add `CustomPlaygroundQuickLookable`
>> conformance?
> 
> Ahhh... yeah, I didn't realize that, and we don't have time to change
> that restriction for Swift 3.  It's not a problem for
> corelibs-foundation but it would be for 3rd-party libraries.  
> 
> OK, Dmitri and I just figured out how we can change the home of these
> types for Swift 4 without breaking Swift 3 code (mirrors to the rescue!)
> So I'm going to withdraw this part of the proposal.

Will the following need to be reverted?









>>> * Deprecate the Indexable protocols with a message indicating that they
>>> will be gone in Swift 4.  These protocols are implementation details
>>> of the standard library designed to work around language limitations
>>> that we expect to be gone in Swift 4.  There's no reason for anyone to
>>> ever touch these; users should always use a corresponding Collection
>>> protocol (e.g. instead of MutableIndexable, use MutableCollection).
>>> 
>>> * Deprecate the ExpressibleByStringInterpolation protocol with a
>>> message indicating that its design is expected to change.  We know
>>> this protocol to be mis-designed
>>> (https://bugs.swift.org/browse/SR-1260) and limited
>>> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>>> for Swift 3.  If we knew what the new design should look like, we
>>> might be able to calculate that the current API is supportable in a
>>> forward-compatible way (as we do for Comparable).  Unfortunately, we
>>> do not.
>>> 
>>> * Rename Streamable to TextOutputStreamable and add a deprecated
>>> Streamable typealias for it.  Now that OutputStream been renamed to
>>> TextOutputStream, we should also move Streamable out of the way.

In apple/swift#4131, these lines have overrun the 80 column limit:







TextFormatting.rst also needs `Streamable` => `TextOutputStreamable`:



>>> Deprecation is being proposed instead of underscoring or renaming
>>> because it allows existing code to keep working (with warnings).  At
>>> this late stage, it would be bad to actually break anything.
>> 
>> If the SE-0104 (protocol-oriented integers) proposal has been deferred, 
>> should any protocols (e.g. SignedNumber) be deprecated?

Will the SE-0104 proposal be accepted for Swift 4.0?

-- Ben

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

Re: [swift-evolution] ABI of throwing

[David Hart via swift-evolution]

I laughed! I've had the same thoughts.

Sent from my iPhone
> On 10 Aug 2016, at 01:22, John McCall via swift-evolution 
>  wrote:
> 
> Aside: I keep running into people writing things like JSON deserializers who 
> for some reason insist on making their lives unnecessarily difficult by 
> manually messing around with Optional/Either results or writing their own 
> monad + combinator libraries or what not.  Folks, there's an error monad 
> built into the language, and it is designed exactly for this kind of 
> error-propagation problem; please just use it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution