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

As has already been said, “case unknown” is source-breaking because it conflicts with any real cases named “unknown”; “\unknown” looks like a key path but isn’t, and I wonder if it would potentially conflict with existing key paths. In any case, my point was not to bikeshed the “unknown” part,

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

> On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution > wrote: > > This is a very nice revision. One bikeshedding thought: > > Since "unknown case" is presented as a special kind of "default", can't be > mixed with "default", and can't be used in case

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

This is a very nice revision. One bikeshedding thought: Since "unknown case" is presented as a special kind of "default", can't be mixed with "default", and can't be used in case patterns, why not "default unknown" (or "unknown default") instead of "unknown case"? On Wed, Jan 3, 2018 at 8:05

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

> 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 C: > > class D: C { var state = 0 } > > var d = D() //

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

> On Jan 2, 2018, at 18:07, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > ] > > Whew!

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

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 C: class D: C { var state = 0 } var d = D() // Bad but common habit of declaring objects as var for i in 1...5 { d.f(i); d.state += 1 }

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

> On 3. Jan 2018, at 18:49, Dave DeLong via swift-evolution > wrote: > > > >> On Jan 3, 2018, at 10:36 AM, Matthew Johnson > > wrote: >> >> >>> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution

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

Sent from my iPad > On Jan 3, 2018, at 12:20 PM, Dave DeLong wrote: > > > >>> On Jan 3, 2018, at 11:09 AM, Matthew Johnson wrote: >>> >>> On Jan 3, 2018, at 12:02 PM, Dave DeLong wrote: On

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

> On Jan 3, 2018, at 11:09 AM, Matthew Johnson wrote: > >> >> On Jan 3, 2018, at 12:02 PM, Dave DeLong > > wrote: >> >> >> >>> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger >>

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

> On Jan 3, 2018, at 12:02 PM, Dave DeLong wrote: > > > >> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger > > wrote: >> > [...] > 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app > author,

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

> On Jan 3, 2018, at 11:49 AM, Dave DeLong wrote: > > > >> On Jan 3, 2018, at 10:36 AM, Matthew Johnson > > wrote: >> >> >>> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution >>>

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

> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger wrote: > [...] 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app author, have to account for the possibility that the module may update from underneath my app, and I have to handle an

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

>>> [...] >>> 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app >>> author, have to account for the possibility that the module may update from >>> underneath my app, and I have to handle an unknown case. This is simple: >>> the compiler should require me to add a “default:”

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

> On Jan 3, 2018, at 11:47 AM, BJ Homer wrote: > > > >> On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> This does not help people who need to write a switch statement over an

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

> On Jan 3, 2018, at 10:36 AM, Matthew Johnson wrote: > > >> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution >> > wrote: >> >> IMO this is still too large of a hammer for this problem. >> >>

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

> On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution > wrote: > > This does not help people who need to write a switch statement over an enum > vended by a module that ships with the OS keep their code up to date as the > module adds new cases. I

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

> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution > wrote: > > IMO this is still too large of a hammer for this problem. > > This whole “unexpected case” thing is only a problem when you’re linking > libraries that are external to/shipped independently

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

> On 3 Jan 2018, at 02:07, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > ] > > Whew! Thanks for your feedback,

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

IMO this is still too large of a hammer for this problem. 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 on the server. We *might* run in to

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

> On Jan 2, 2018, at 10:26 PM, Kelvin Ma via swift-evolution > wrote: > > > > On Tue, Jan 2, 2018 at 11:45 PM, Nevin Brackett-Rozinsky via swift-evolution > > wrote: > On Tue, Jan 2, 2018 at 9:07 PM,

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

Despite having suggested the @version syntax I do agree with people that have said any @annotation is both a burden on the programmer and severely reduces readability. Therefore a 4th option, carrying on from the numbering in my previous email is: 4. The compiler issues a description of the

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

Is it hard to imagine that most everyone can get what they want and keep the syntax clean and streamlined at the same time? Without any "@" signs or other compiler hints? "Rather, we are how to enable the vendor of a nonexhaustive enum to add new > cases without breaking binaries compiled against