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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

> 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

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

> 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

[swift-evolution] Swiftier implementation of Measurement and Unit

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

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

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,

Re: [swift-evolution] [Pitch] Rename Mirror

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 >

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

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

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

> 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

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

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

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

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

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

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

Re: [swift-evolution] [Pitch] Rename Mirror

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

Re: [swift-evolution] ABI of throwing

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