Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Xiaodi Wu via swift-evolution
On Fri, Jan 5, 2018 at 01:56 Jonathan Hull wrote: > On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez wrote: > > >> On Jan 4, 2018, at 4:37 PM, Xiaodi Wu wrote: >> >> On Thu, Jan 4, 2018 at 19:29 Che

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Jonathan Hull via swift-evolution
> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez > wrote: > > On Jan 4, 2018, at 4:37 PM, Xiaodi Wu > wrote: > >> On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez >

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Xiaodi Wu via swift-evolution
On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez wrote: > > > On Jan 4, 2018, at 4:37 PM, Xiaodi Wu wrote: > > > On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez wrote: > >> On Jan 4, 2018, at 3:50 PM, Xiaodi Wu wrote: >> >> >> On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez >> wrote: >> >>> >>> On Jan

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Cheyo Jimenez via swift-evolution
> On Jan 4, 2018, at 4:37 PM, Xiaodi Wu wrote: > > > On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez wrote: >>> On Jan 4, 2018, at 3:50 PM, Xiaodi Wu wrote: >>> >>> >>> On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez wrote: > On Jan 4, 2018, at 2:55 PM, Xiaodi Wu wrote: >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Gwendal Roué via swift-evolution
May I ask two questions? Would StoreKit be written in Swift 5+, do you think that SKPaymentTransactionState should have been introduced as a @closed enum? If so, what would have then been the consequences of adding the new .deferred state (assuming this would even be possible)? Gwendal > Le 5

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Gwendal Roué via swift-evolution
Thanks for this extended rationale. I would pin this post if I could. Or extend the "motivation" section of the proposal with it. Gwendal > Le 5 janv. 2018 à 01:38, Jordan Rose via swift-evolution > a écrit : > > Hi, Dave. You're right, all these points are worth addressing. I'm going to >

Re: [swift-evolution] Renaming SwiftObject

2018-01-04 Thread Xiaodi Wu via swift-evolution
If it’s the base class for all Swift class types, I think “SwiftObject” is ideal and the proposed renaming is sensible. What does it matter that it’s an Obj-C object? Why does that have to be in the name? Let’s not bikeshed this and keep it simple. On Thu, Jan 4, 2018 at 22:21 Félix Cloutier via s

Re: [swift-evolution] Renaming SwiftObject

2018-01-04 Thread Félix Cloutier via swift-evolution
I'll bite. Shouldn't that name encode that it's an Objective-C object? Like Swift.ObjCBase? > Le 4 janv. 2018 à 22:10, Greg Parker via swift-evolution > a écrit : > > SwiftObject is an Objective-C class that is the base class of all "pure > Swift" class types. It needs to be renamed for the S

[swift-evolution] Renaming SwiftObject

2018-01-04 Thread Greg Parker via swift-evolution
SwiftObject is an Objective-C class that is the base class of all "pure Swift" class types. It needs to be renamed for the Swift stable ABI in order to avoid ObjC class name collisions between the stable ABI's Swift runtime and the runtime embedded into existing Swift apps. I suggest `Swift._Ob

Re: [swift-evolution] DynamicMemberLookup proposal: status update

2018-01-04 Thread Chris Lattner via swift-evolution
On Jan 4, 2018, at 3:43 PM, Nevin Brackett-Rozinsky wrote: > > There’s a lot of information here and it’ll take some time to process it all. > My initial reaction is that a “strong type-alias” feature might help. If one > could write (strawman syntax): > > strong typealias Dog = PyVal// A

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Jordan Rose via swift-evolution
Hi, Dave. You're right, all these points are worth addressing. I'm going to go in sections. > This whole “unexpected case” thing is only a problem when you’re linking > libraries that are external to/shipped independently of your app. Right now, > the *only* case where this might exist is Swift

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Xiaodi Wu via swift-evolution
On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez wrote: > On Jan 4, 2018, at 3:50 PM, Xiaodi Wu wrote: > > > On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez wrote: > >> >> On Jan 4, 2018, at 2:55 PM, Xiaodi Wu wrote: >> >> >> On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez >> wrote: >> >>> On Jan 4,

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Cheyo J. Jimenez via swift-evolution
> On Jan 4, 2018, at 3:50 PM, Xiaodi Wu wrote: > > > On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez > wrote: > >> On Jan 4, 2018, at 2:55 PM, Xiaodi Wu > > wrote: >> >> >> On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez >

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Xiaodi Wu via swift-evolution
On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez wrote: > > On Jan 4, 2018, at 2:55 PM, Xiaodi Wu wrote: > > > On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez wrote: > >> On Jan 4, 2018, at 11:53 AM, Xiaodi Wu wrote: >> >> >> On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez wrote: >> >>> >>> >>> On Jan

Re: [swift-evolution] DynamicMemberLookup proposal: status update

2018-01-04 Thread Nevin Brackett-Rozinsky via swift-evolution
There’s a lot of information here and it’ll take some time to process it all. My initial reaction is that a “strong type-alias” feature might help. If one could write (strawman syntax): strong typealias Dog = PyVal// A semantically independent new type extension Dog { // Declarations here

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Cheyo J. Jimenez via swift-evolution
> On Jan 4, 2018, at 2:55 PM, Xiaodi Wu wrote: > > > On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez > wrote: >> On Jan 4, 2018, at 11:53 AM, Xiaodi Wu > > wrote: >> >> >> On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez >

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Xiaodi Wu via swift-evolution
On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez wrote: > On Jan 4, 2018, at 11:53 AM, Xiaodi Wu wrote: > > > On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez wrote: > >> >> >> On Jan 4, 2018, at 10:49 AM, Jordan Rose wrote: >> >> I'll admit I hadn't thought of using "unknown default" (or "default >> u

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Cheyo J. Jimenez via swift-evolution
> On Jan 4, 2018, at 11:53 AM, Xiaodi Wu wrote: > > > On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez > wrote: > > > On Jan 4, 2018, at 10:49 AM, Jordan Rose > wrote: > >> I'll admit I hadn't thought of using "unknown default" (or "defau

[swift-evolution] DynamicMemberLookup proposal: status update

2018-01-04 Thread Chris Lattner via swift-evolution
Hi everyone, With the holidays and many other things behind us, the core team had a chance to talk about python interop + the dynamic member lookup proposal recently. Here’s where things stand: we specifically discussed whether a counter-proposal of using “automatically generated wrappers” or “

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Xiaodi Wu via swift-evolution
On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez wrote: > > > On Jan 4, 2018, at 10:49 AM, Jordan Rose wrote: > > I'll admit I hadn't thought of using "unknown default" (or "default > unknown"). I don't think that's terrible, but I mildly prefer `unknown > case` because it builds on the "pun" that enu

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Jordan Rose via swift-evolution
> On Jan 4, 2018, at 11:45, Cheyo Jimenez wrote: > > > > On Jan 4, 2018, at 10:49 AM, Jordan Rose > wrote: > >> I'll admit I hadn't thought of using "unknown default" (or "default >> unknown"). I don't think that's terrible, but I mildly prefer `unknown case`

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Cheyo Jimenez via swift-evolution
> On Jan 4, 2018, at 10:49 AM, Jordan Rose wrote: > > I'll admit I hadn't thought of using "unknown default" (or "default > unknown"). I don't think that's terrible, but I mildly prefer `unknown case` > because it builds on the "pun" that enum elements are also defined using > 'case'. If any

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

2018-01-04 Thread Hooman Mehr via swift-evolution
> On Jan 3, 2018, at 6:45 PM, Slava Pestov wrote: >> On Jan 3, 2018, at 5:33 PM, Hooman Mehr > > wrote: >> Thank you Slava, it is a very insightful answer. >> It also reveals a potential source for hard to track bugs. To make it easier >> to see, lets add state to class

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Jordan Rose via swift-evolution
I'll admit I hadn't thought of using "unknown default" (or "default unknown"). I don't think that's terrible, but I mildly prefer `unknown case` because it builds on the "pun" that enum elements are also defined using 'case'. If anything hits this part of the switch, it really will be an "unknow

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Nevin Brackett-Rozinsky via swift-evolution
On Thu, Jan 4, 2018 at 8:23 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 3, 2018, at 10:02 AM, Dave DeLong via swift-evolution < > swift-evolution@swift.org> wrote: > > 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on > externall

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

2018-01-04 Thread Brent Royal-Gordon via swift-evolution
> On Jan 3, 2018, at 10:02 AM, Dave DeLong via swift-evolution > wrote: > > 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on > externally-linked modules Naming is serious business, Dave. Let it go. *ducks* -- Brent Royal-Gordon Architechies __