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

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

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

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 >

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

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

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

> 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] DynamicMemberLookup proposal: status update

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

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

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

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

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

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

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

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

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

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

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

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

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

[swift-evolution] DynamicMemberLookup proposal: status update

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] Preserving non-mutability of methods of an existential or generic object

> 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

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

> 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

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

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 >

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

> 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

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

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

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

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

[swift-evolution] Renaming SwiftObject

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

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

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

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

> 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

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

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:

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

> 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

Re: [swift-evolution] Renaming SwiftObject

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

Re: [swift-evolution] Renaming SwiftObject

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

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

> 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