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

Clarifications here only! I don't think I have too much more to convince you; at this point we've looked at the same landscape and come to different conclusions. Although I think I'm more optimistic than you are about being able to build a binary compatibility checker. > On Jan 5, 2018, at

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

> On 5. Jan 2018, at 15:52, Swift via swift-evolution > wrote: > > Hi Jordan, > > Thanks for your thoughtful reply. Comments inline... > > Sent from my iPad > > On Jan 4, 2018, at 5:37 PM, Jordan Rose >

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

Hi Jordan, Thanks for your thoughtful reply. Comments inline... Sent from my iPad > On Jan 4, 2018, at 5:37 PM, Jordan Rose wrote: > > Hi, Dave. You're right, all these points are worth addressing. I'm going to > go in sections. > >> This whole “unexpected case” thing

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

> Le 5 janv. 2018 à 10:33, Goffredo Marocchi a écrit : > > Fair concerns Gwendal, but why can’t the default in these cases be just > exhaustive / frozen unless the library developer explicitly marks it as > “unfrozen/non exhaustive” and the compiler can warn the users when

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

Fair concerns Gwendal, but why can’t the default in these cases be just exhaustive / frozen unless the library developer explicitly marks it as “unfrozen/non exhaustive” and the compiler can warn the users when they switch over it instead of throwing an error by default (the user can still

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

> Le 5 janv. 2018 à 09:11, Goffredo Marocchi via swift-evolution > a écrit : > > I feel like this change will make the life easier for library authors, but > risks making it easier and easier to make mistakes in apps using the > libraries: exhaustive switching over

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

Code that ends up running in a default case somewhere in one of the several places you switch over that enum that you forgot about... well, it may not break source code compatibility, but it may introduce subtle bugs... submarine bugs. Sent from my iPhone > On 5 Jan 2018, at 08:11, Goffredo

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

> On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution > wrote: > > Furthermore, the old code needs to continue working without source changes, > because updating to a new SDK must not break existing code. (It can introduce > new warnings, but even that is

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

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] [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] [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] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Sent from my iPhone > On 3 Jan 2018, at 07:42, Goffredo Marocchi wrote: > > >> On 3 Jan 2018, at 02:07, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >>

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

I am not convinced by these arguments, they seem to be a ‘poor man’s’ versioning system. For example consider: // In module. public enum E { case A, B, C } // In application. switch e { case A: a() default: d() unknown case: u() } When e == B or C

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

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, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > >> [Proposal: https://github.com/apple/swift-evolution/blob/mas >>

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

On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > [Proposal: https://github.com/apple/swift-evolution/blob/ > master/proposals/0192-non-exhaustive-enums.md] > > Whew! Thanks for your feedback, everyone. On the lighter side of > feedback—naming

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

On Tue, Jan 2, 2018 at 8:49 PM, Matthew Johnson wrote: > > On Jan 2, 2018, at 8:45 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Jan 2, 2018 at 8:07 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > >>

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

> On Jan 2, 2018, at 8:45 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jan 2, 2018 at 8:07 PM, Jordan Rose via swift-evolution > > wrote: > [Proposal: >

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

On Tue, Jan 2, 2018 at 8:07 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > [Proposal: https://github.com/apple/swift-evolution/blob/ > master/proposals/0192-non-exhaustive-enums.md] > > Whew! Thanks for your feedback, everyone. On the lighter side of > feedback—naming

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

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

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md ] Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it

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

First, this is an extremely well-written proposal, that explains itself well and tries to walk a difficult tightrope.  So, A+ for that. That said, I think it needs modification before acceptance: * I agree with Dave DeLong that @exhaustive does not actually "do anything", it relies on library

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

-1 It took awhile to catch up. I understand the motivation but don't agree with the solution. The suggested proposal adds language complexity that can hopefully be solved in other ways. In catching up I related to Howard Lovatt's response. Jordan responded: > On Dec 20, 2017, at 2:33 PM,

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

Hello I would like to give a feedback on this SE, In the proposal, it stats that In the initial discussion, multiple people were unhappy with the loss of compiler warnings for switches over non-exhaustive enums that comes with using default—they wanted to be able to handle all cases that exist

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

Oops, I meant to post this on a separate thread. Sorry. Sincerely, Natchanon ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

Before answering above, I would like to add Since the users of the library will likely not accommodate the new cases (as it doesn’t exist yet), the `default/future` case will then not provide any real usage other than throwing exceptions. So the user will still need to update the code to

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

I can see why this is useful, and understand the problem. However, it does feel like the wrong solution to a real problem. This seems to be very similar to the *expression problem*: > The expression problem is a new name for an old problem.[2][3] The goal is to define a datatype by cases, where

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

> I am part of the people mentioned in "Preserve exhaustiveness diagnostics for > non-exhaustive enums" : I see the completeness check as a major feature of > enums, that makes a difference between it and a list of constants in multiple > cases. > So much that in the coding rules of the

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

> On Dec 19, 2017, at 20:15, Howard Lovatt via swift-evolution > wrote: > > As an aside: there seems to be increasingly comments about proposals that say: > > 1. This was discussed at the evaluation stage and rejected. > 2. This is how it is implemented in the

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

Thanks for your feedback! I think you're missing the "libraries in the OS" aspect of this: if there are Swift libraries in iOS, and Apple ships a software update, some enums will get new cases. That means you can always end up in a default case if you were switching over those enums, and that's

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

Thanks for your thoughts. I think 3) is indeed a very common case, but also not affected by this proposal or the general issue at all. Unless I’m missing something, I think it makes sense to limit the discussion to those enums that are typically switched over in client code. I don’t think 1)

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

> On Dec 20, 2017, at 1:00 AM, Sebastian Hagedorn via swift-evolution > wrote: > >> The expectation is that switches over non-exhaustive enums are uncommon. > > > Basically every time I interact with an enum, I switch over it, to make sure > I don’t forget

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

Hi guys, I am part of the people mentioned in "Preserve exhaustiveness diagnostics for non-exhaustive enums" : I see the completeness check as a major feature of enums, that makes a difference between it and a list of constants in multiple cases. So much that in the coding rules of the company

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

> What is your evaluation of the proposal? > +1 if a `future` case (or similar solution… “unknown” might be a nice keyword, although some enums probably have an `.unknown` case which could be confusing) is added. > Is the problem being addressed significant enough to warrant a change to >

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

On Wed, Dec 20, 2017 at 12:42 AM, Howard Lovatt wrote: > Let me give an example. The recent discussion about filterMap aired in the > discussion stage misgivings about the name; but it went to review with the > name filterMap. At the review stage more misgivings were

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

Let me give an example. The recent discussion about filterMap aired in the discussion stage misgivings about the name; but it went to review with the name filterMap. At the review stage more misgivings were raised, the review was returned for amendment. An amended name of compactMap was put

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

On Tue, Dec 19, 2017 at 11:15 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > As an aside: there seems to be increasingly comments about proposals that > say: > > 1. This was discussed at the evaluation stage and rejected. > 2. This is how it is implemented in the

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

As an aside: there seems to be increasingly comments about proposals that say: 1. This was discussed at the evaluation stage and rejected. 2. This is how it is implemented in the patch. And other comments along those lines. Neither the pre-proposal discussions nor the proposed

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

They would not be boxed, but there would be additional indirection required at runtime, using the same mechanism currently used for unspecialized generics. Slava > On Dec 19, 2017, at 6:42 PM, Kevin Ballard wrote: > > Isn’t this going to turn both structs and non-C-like enums

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

Isn’t this going to turn both structs and non-C-like enums into types that need to be auto-boxed (as the client won’t be able to rely on knowing the fixed size anymore)? This seems like a performance hazard. -Kevin Ballard > On Dec 19, 2017, at 5:35 PM, Slava Pestov wrote:

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

> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution > wrote: > > So I guess I’m saying, I want more thought put on the topic of whether enums > defined in Swift should actually default to non-exhaustive, and I’m now > leaning towards the idea that

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

On Tue, Dec 19, 2017 at 6:31 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote: > > https://github.com/apple/swift-evolution/blob/master/ > proposals/0192-non-exhaustive-enums.md > > >- > >

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

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > > What is your evaluation of