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

I'm not sure how this solves the problem. We need to know whether an enum may grow new cases or not, a concept that doesn't exist in Swift today. This is most interesting for enums in "libraries with binary compatibility concerns", but is also interesting for libraries that don't have such conce

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

Having reviewed much of the commentary on this proposal, I keep coming back to the same thought: why not use @versioned and @available keywords for this instead of some concept related to “exhaustive”? The issue here is not whether a given enum is “exhaustive” over the enumerated problem space;

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

It's true that Apple framework authors have this capability, known as a "linked-on-or-after check", but it has several caveats: - It can only check what SDK the application was linked against. Any prebuilt libraries that the application uses might have been built against an older or newer SDK.

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

Add -Weverything and you can ensure you are switching exhaustively ;). Sent from my iPhone > On 8 Jan 2018, at 19:02, Javier Soto via swift-evolution > wrote: > > This is very much an issue in Obj-C today. If you have an NS_ENUM defined > with cases A, B, and C, this switch is correct: > > i

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

hello, im not sure I like this. I think new cases to switches should always break an app. :) > Am 19.12.2017 um 14:58 schrieb Ted Kremenek via swift-evolution > : > > The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through > January 3, 2018. > > The proposal is available he

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

Why isn't that a problem today? Like I showed in that example, that's undefined behavior and will potentially result in a bug (or even a crash if instead of an int you end up with an unexpected nil pointer) On Sat, Jan 6, 2018 at 4:47 PM Jon Shier wrote: > Which isn’t a problem right now, AFAICT

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

Which isn’t a problem right now, AFAICT. Apps compiled under older SDKs continue to work fine (sometimes better than when compiled under the new SDK, as the older one avoids new bugs). My question is about how that compatibility is accomplished today and how and why the Obj-C and Swift cases are

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

What doesn't happen today? The issue is not when they ship a new SDK: When rebuilding your app against it, you'll get a warning for a missing case. The problem is when running the app against a newer iOS version with a newer version of the SDK where the enum has a new case. On Sat, Jan 6, 2018 at 3

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

Except it clearly doesn’t happen today when Apple ships new SDKs. Obviously there’s an alternate mechanism used in that case. I’m just curious what it is and why Swift so desperately needs an alternative. Jon > On Jan 6, 2018, at 5:49 PM, Javier Soto wrote: > > This is very much an issue i

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

This is very much an issue in Obj-C today. If you have an NS_ENUM defined with cases A, B, and C, this switch is correct: int foo; swith (e) { case A: foo = 0; break; case B: foo = 1; break; case C: foo = 2; break; } (Note the lack of a default case) If that enum is defined in a framework and it

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

(Disclaimer: I’m no expert in this, and I know there are people in this list that are, so if there’s anything wrong please feel free to step in and correct me) As far as I’m aware, Apple’s frameworks check which version of the framework you linked with at runtime (for UIKit, I believe this func

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

There are a number of things being talked about in this thread, all of which are solved by proper automated IDE tooling. Javier, In my opinion the situation you've described is based on how overall nil is handled by the language parser before it generates LLVM IR. A smart compiler would know what

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

> Le 6 janv. 2018 à 04:11, Jon Shier via swift-evolution > a écrit : > > At this point I think it might be useful to outline how binary compatibility > works for Objective-C on Apple platforms right now. As an app developer I’m > not intimately familiar with what happens when you run an app

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

At this point I think it might be useful to outline how binary compatibility works for Objective-C on Apple platforms right now. As an app developer I’m not intimately familiar with what happens when you run an app compiled with the iOS 10 SDK on iOS 11. Are there just runtime checks to call old

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

> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution > wrote: > > 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? For what it's worth, the original versio

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

Oh, I see… the case would silently change from unexpected to default if they were both included. Hmm. I will have to think on this more. Thanks, Jon > On Jan 5, 2018, at 3:17 PM, Jordan Rose wrote: > > > >> On Jan 5, 2018, at 00:11, Jonathan Hull via swift-evolution >> mailto:swift-evolut

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

> On Jan 5, 2018, at 00:11, Jonathan Hull via swift-evolution > wrote: > >> >> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu > > wrote: >> >> >> On Fri, Jan 5, 2018 at 01:56 Jonathan Hull > > wrote: >>> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via s

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

> On Jan 5, 2018, at 4:42 AM, Xiaodi Wu wrote: > > > On Fri, Jan 5, 2018 at 03:11 Jonathan Hull > wrote: >> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu > > wrote: >> >> >> On Fri, Jan 5, 2018 at 01:56 Jonathan Hull > > wrot

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

On Fri, Jan 5, 2018 at 03:11 Jonathan Hull wrote: > On Jan 4, 2018, at 11:02 PM, Xiaodi Wu wrote: > > > 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

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

> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu wrote: > > > On Fri, Jan 5, 2018 at 01:56 Jonathan Hull > wrote: >> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: > >> >> On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez >

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 wrote: >> >> On Thu, Jan 4, 2018 at 19:29 Che

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 > wrote: > >> On Thu, Jan 4, 2018 at 19:29 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: >> >> >> On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez >> wrote: >> >>> >>> On Jan

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 wrote: > On Jan 4, 2018, at 2:55 PM, Xiaodi Wu wrote: >

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

> 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

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] [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: >> >> >> On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez >

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 wrote: >> >> I'll admit I hadn't thought of using "unknown default" (or "default >> u

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: > >> I'll admit I hadn't thought of using "unknown default" (or "defau

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 > case` because it builds on the "pun" that enu

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 that's terrible, but I mildly prefer `unknown case`

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 using > 'case'. If any

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

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

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

This is not what I am saying. Change X helps use case A, but unnecessarily removes feature important (and like argument labels for everything quite Swift defining, but alas...) for use case B. What I am saying is that before merging change X we should figure out what is needed (change Y) to en

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

On Tue, Jan 2, 2018 at 8:25 PM, Matthew Johnson wrote: > > On Jan 2, 2018, at 3:41 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger > wrote: > >> [...] >> >> in what other circumstances do we insist that the compiler inform the end >>> user about future additions to the

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

> On Jan 2, 2018, at 2:09 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 1:46 PM, Matthew Johnson > wrote: > > > Sent from my iPad > > On Jan 2, 2018, at 12:48 PM, Xiaodi Wu > wrote: > >> On Tue, Jan 2, 2018 at 9:38 AM, Matthew Jo

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

> On Jan 2, 2018, at 3:41 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger > wrote: > [...] > >>> in what other circumstances do we insist that the compiler inform the end >>> user about future additions to the API at compile time? >> >> Th

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

On Tue, Jan 2, 2018 at 7:02 PM, Goffredo Marocchi wrote: > > On 3 Jan 2018, at 00:38, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull wrote: > >> I think there are a couple of different definitions running around, and >> that

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

> On 3 Jan 2018, at 00:38, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull wrote: >> I think there are a couple of different definitions running around, and that >> is confusing things. >> >> In my mind, ‘unexpected:’ catches only cases which were un

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

On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull wrote: > I think there are a couple of different definitions running around, and > that is confusing things. > > In my mind, ‘unexpected:’ catches only cases which were unknown at compile > time. Adding cases to an enum *should* be a source-breaking c

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

In regards of A, doesn’t this code cover al cases? @incomplete enum { case pancake case waffle case juice } When the @incomplete tag is present, the compiler enforces (with an error) that all switches handle a default case: switch breakfast { case .pancake: case .waffle: case .juice

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

I think there are a couple of different definitions running around, and that is confusing things. In my mind, ‘unexpected:’ catches only cases which were unknown at compile time. Adding cases to an enum *should* be a source-breaking change. That is the whole point of this. We should have to up

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

I think this is a good summary. I agree that we need to handle unexpected cases from changes to a binary somehow. The main issue is that, when forcing developers to use ‘default’ to do it, it also brings along unwanted semantics that prevent warnings in the very common use case of a 3rd part

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

On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger wrote: > [...] > > in what other circumstances do we insist that the compiler inform the end >> user about future additions to the API at compile time? >> >> >> This isn’t a request for the compiler to inform the user about future >> additions to an

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

[...] >> in what other circumstances do we insist that the compiler inform the end >> user about future additions to the API at compile time? > > This isn’t a request for the compiler to inform the user about future > additions to an API. It is a request to validate the compiler’s knowledge of

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

> On 2. Jan 2018, at 16:38, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Jan 1, 2018, at 11:47 PM, Chris Lattner > wrote: > >>> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution >>> mailto:swift-evolution@swift.

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

On Tue, Jan 2, 2018 at 1:46 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Jan 2, 2018, at 12:48 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 9:38 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> Sent from my iPad >> >> On Jan 1, 2018, at 11:

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

Sent from my iPad > On Jan 2, 2018, at 12:48 PM, Xiaodi Wu wrote: > >> On Tue, Jan 2, 2018 at 9:38 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >> Sent from my iPad >> >> On Jan 1, 2018, at 11:47 PM, Chris Lattner wrote: >> On Dec 31, 2017, at 12:14 PM, Matthew Johnson v

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

On Tue, Jan 2, 2018 at 1:27 PM, Goffredo Marocchi wrote: > Hello all, > > On 2 Jan 2018, at 18:36, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution < > swift-evolution@swift.org> wrote: > >> I think this wh

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

Hello all, > On 2 Jan 2018, at 18:36, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution >> wrote: >> I think this whole thing has been unnecessarily convoluted. As a result, the >> majority of the replies are rabbit holes. >> >>

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

On Tue, Jan 2, 2018 at 9:38 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Jan 1, 2018, at 11:47 PM, Chris Lattner wrote: > > On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > I a

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

On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution < swift-evolution@swift.org> wrote: > I think this whole thing has been unnecessarily convoluted. As a result, > the majority of the replies are rabbit holes. > > In my opinion, the true root of the concept in question is as follo

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

I think this whole thing has been unnecessarily convoluted. As a result, the majority of the replies are rabbit holes. In my opinion, the true root of the concept in question is as follows: *A list of something is desired:* 1 - Pancake 2 - Waffle 3 - Juice *Developer wishes to be able to:* *A)*

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

Sent from my iPad >> On Jan 1, 2018, at 11:47 PM, Chris Lattner wrote: >> >> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution >> wrote: >> >> I agree that we need a solution to the problem described. I also agree that >> non-exhaustive is most in keeping with the overall

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

...@anandabits.comAntworten: clatt...@nondot.orgCc: swift-evolution@swift.orgBetreff: Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:I agree that we need a solution to the p

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

On Tue, Jan 2, 2018 at 12:47 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > 1) When dealing with independently updated binary packages, your code > *has* to implement some behavior for unexpected cases if the enum is > non-exhaustive. It isn’t acceptable to not han

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

> On Jan 1, 2018, at 10:47 PM, Chris Lattner via swift-evolution > wrote: > >> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I agree that we need a solution to the problem described. I also agree that >> non-exhaustive

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

> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution > wrote: > > I agree that we need a solution to the problem described. I also agree that > non-exhaustive is most in keeping with the overall design of Swift at module > boundaries. However, I believe this proposal should be

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

> On Dec 31, 2017, at 1:21 PM, Cheyo Jimenez wrote: > > > > On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution > wrote: > >>> On 21 Dec 2017, at 03:32, John McCall wrote: >>> > On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote: > > On Dec 19, 2017, at 2:58 PM

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

I have been busy over the holidays and have been considering the arguments in this thread so my review is late in coming. > What is your evaluation of the proposal? > I agree that we need a solution to the problem described. I also agree that non-exhaustive is most in keeping with the overall d

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

On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution wrote: >> On 21 Dec 2017, at 03:32, John McCall wrote: >> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote: On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote: • What is your evaluation of the pro

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

> On 21 Dec 2017, at 03:32, John McCall wrote: > >> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote: >> >>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote: >>> >>> • What is your evaluation of the proposal? >> >> I am pleased with the broad strokes of this design. I have quibbles wi

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

> Le 28 déc. 2017 à 21:17, Eneko Alonso via swift-evolution > a écrit : > > Hello everyone, > > My name is Eneko Alonso, iOS developer, new here on the list. > > Is there a good summary anywhere that condenses the pros and cons of this new > feature that have been discussed so far? > > It

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

Hello everyone, My name is Eneko Alonso, iOS developer, new here on the list. Is there a good summary anywhere that condenses the pros and cons of this new feature that have been discussed so far? It is not clear to me why non-exhaustive would be the default, requiring adding `@exhaustive` ot

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

Actually, from the other email thread about this same topic (thank god forums are almost here), I see the proposed syntax “final switch” for what I referred to as “switch!”, which I prefer. > On Dec 28, 2017, at 12:17 AM, Riley Testut via swift-evolution > wrote: > > -1. > > I agree this is

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

-1. I agree this is a problem, but I think this is the wrong solution. I think the solution should be on the client side, not on the framework author’s side. I would be fine if enums from imported modules are non-exhaustive, as long as I can choose to treat them as exhaustive if I want to. And

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

> On Dec 25, 2017, at 9:14 AM, Cheyo Jimenez via swift-evolution > wrote: > > > >> On Dec 22, 2017, at 8:49 AM, Cheyo Jose Jimenez wrote: >> >> >> >>> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez wrote: >>> >>> >>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >>

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

> The proposal is available here: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > > What is your evaluation of the proposal? > -1 I would much prefe

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

Sorry to glomm on to my own comments: I think there’s a lot of reasonable push-back to requiring a default case on non-exhaustive enums. I personally don’t want to see a “future case” because I think it’s mystery-meat. However, in the happy path, as a developer I do want *some* notification by the

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

On Tue, Dec 19, 2017, at 5:58 PM, Ted Kremenek wrote: > * What is your evaluation of the proposal? +1. I strongly prefer all additions to service ABI follow progressive disclosure, but it’s not reason alone to make the annotation be mystery meat. Like the inlining proposal, the spelling needs som

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

> On Dec 22, 2017, at 8:49 AM, Cheyo Jose Jimenez wrote: > > > >> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez wrote: >> >> >> >>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >>> wrote: >>> >>> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through

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

Hi Dave, The broader problem is being considered holistically, and we’re designing and implementing various pieces of the solution as part of the ABI stability effort for Swift 5. Some of these pieces impact the language, hence you’ll be seeing some evolution proposals. Non-exhaustive enums is

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

> On Dec 23, 2017, at 3:19 AM, Thomas Roughton via swift-evolution > wrote: > > Looking at the feedback to this proposal, it looks like a common thread is > people wanting to make sure they’re notified when new cases are introduced > (the ‘future’ keyword’). However, if I’m understanding cor

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

Continuing on this vein, there is another huge reason this proposal is incomplete and won’t solve the problem. This proposal, as I outlined previously, is all about binary compatibility and functional resilience in the face of changing libraries. However, it falls woefully short by only conside

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

> On Dec 21, 2017, at 11:07 AM, Jordan Rose wrote: > > Thanks for your comments, Jon. Responses inline. > >> On Dec 20, 2017, at 12:46, Jonathan Hull > > wrote: >> >> >>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >>> mailto:swift-evolution@swift.org

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

Looking at the feedback to this proposal, it looks like a common thread is people wanting to make sure they’re notified when new cases are introduced (the ‘future’ keyword’). However, if I’m understanding correctly, the resistance to adding such a keyword is that it becomes complicated when ther

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

> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez wrote: > > > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> wrote: >> >> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through >> January 3, 2018. >> >> The proposal is available here: >> >> https://

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

> On Dec 21, 2017, at 10:02 AM, Dave DeLong via swift-evolution > wrote: > > I would love to see some sort of formal API versioning that we could do > instead in libraries, along with easy runtime support for checking the linked > version of libraries, making it easy to strategize implementati

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

> On Dec 21, 2017, at 8:17 PM, Jordan Rose wrote: > > > >> On Dec 20, 2017, at 12:54, Charlie Monroe > > wrote: >> >> I think that the main confusion here stems from the word library as we are >> addressing something that can be divided further (and this is

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

Thanks for this response, John. I think you’re right. This would be very helpful. It a) helps those who are source compiling with their app, and b) avoids fragmenting the language because it would be a core understanding of the code you are compiling, rather than creating a new “variant” of Swi

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

I very much agree with the high-level of the proposal. The concept definitely needs to exist. However, I feel that the options presented do so in a non-intuitive way. There are two concepts here: closed and open listing of values that make up a set of possible options to be used. I think of thi

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

I agree with everything said by Brent Royal-Gordon, however a -1 without the addition of a `future` case or something similar. - What is your evaluation of the proposal? -1, this solution solves a real problem but introduces a very significant drawback. It should include a solution that pr

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

> On Dec 21, 2017, at 2:17 PM, John McCall wrote: > > >> On Dec 21, 2017, at 3:10 PM, Matthew Johnson > > wrote: >> >> >>> On Dec 21, 2017, at 2:06 PM, John McCall >> > wrote: >>> >>> On Dec 21, 2017, at 2:41 PM, Matthew Johnson

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

> On Dec 21, 2017, at 3:10 PM, Matthew Johnson wrote: > > >> On Dec 21, 2017, at 2:06 PM, John McCall > > wrote: >> >> >>> On Dec 21, 2017, at 2:41 PM, Matthew Johnson >> > wrote: >>> >>> On Dec 21, 2017, at 1:26 PM, John McCall

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

Making enums non-exhaustive solves a problem for authors of precompiled frameworks which apps can dynamically link against. These libraries need to preserve binary compatibility, in the sense that apps should continue to work with newer versions of the library. Now, that creates a problem for app

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

> On Dec 21, 2017, at 2:06 PM, John McCall wrote: > > >> On Dec 21, 2017, at 2:41 PM, Matthew Johnson > > wrote: >> >> >>> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Dec 21, 2017

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

> On Dec 21, 2017, at 2:41 PM, Matthew Johnson wrote: > > >> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >

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

+1 kind of eye opening looking at it from that angle :/. Sent from my iPhone > On 21 Dec 2017, at 18:02, Dave DeLong via swift-evolution > wrote: > > I realized further why we should not implement this proposal: It forces the > problem of binary compatibility on the app developer, when experi

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

Okay, thanks Jordan. I appreciate your perspective, and I admit that the proposal is technically compelling. My criticism was from a place of respect and admiration, and while I may have missed the deeper technical points of the proposal, I’ll still caution about how this change will be received

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

> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution > wrote: > >> >> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On Dec 20, 2017, at 12:35, Karl Wagner >> > wrote: >>> >>> >>>

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

> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Dec 20, 2017, at 12:35, Karl Wagner > > wrote: >> >> >> >>> On 20. Dec 2017, at 19:54, Jordan Rose >> > wrote: >>> >>> >>> On Dec 20, 2017, a

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

> On Dec 20, 2017, at 12:54, Charlie Monroe wrote: > > I think that the main confusion here stems from the word library as we are > addressing something that can be divided further (and this is IMHO as many > macOS/iOS devs see it): > > - libraries that come with the OS - here, it absolutely

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

> On Dec 20, 2017, at 12:52, Colin Barrett wrote: > > >> On Dec 20, 2017, at 1:36 PM, Jordan Rose > > wrote: >> >> Thanks for the links, Colin. I think neither of these approaches are >> appropriate for Swift, largely for the same reason: they can't be used to

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

Thanks for your comments, Jon. Responses inline. > On Dec 20, 2017, at 12:46, Jonathan Hull wrote: > > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> When reviewing a proposal, here are some questions to consider: >> >> What is

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

> On Dec 20, 2017, at 12:35, Karl Wagner wrote: > > > >> On 20. Dec 2017, at 19:54, Jordan Rose > > wrote: >> >> >> >>> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> On 19. Dec 201

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

Thanks for your response, Ash. Comments inline. > On Dec 20, 2017, at 11:49, Ash Furrow via swift-evolution > wrote: > > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > >

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

I realized further why we should not implement this proposal: It forces the problem of binary compatibility on the app developer, when experience has shown us that problem is better handled by the libraries. Binary Compatibility “Binary compatibility” is the notion that, even if the libraries y

  1   2   >