Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 17, 2018, at 4:19 PM, Jordan Rose wrote: >>> >>> The parser has fairly general support for declmodifiers, and my proposal >>> fits directly into that. The only extension is that ‘default’ isn’t a >>> decl, and I don’t think we have a statement modifier yet.

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 17, 2018, at 14:42, Jordan Rose wrote: > > > >> On Jan 17, 2018, at 14:41, Chris Lattner > > wrote: >> >>> On Jan 16, 2018, at 10:24 AM, Jordan Rose >> >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 17, 2018, at 14:41, Chris Lattner wrote: > >> On Jan 16, 2018, at 10:24 AM, Jordan Rose > > wrote: On Jan 12, 2018, at 3:08 PM, Jordan Rose >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 16, 2018, at 10:24 AM, Jordan Rose wrote: >>> On Jan 12, 2018, at 3:08 PM, Jordan Rose >> > wrote: >>> >>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's >>> point very

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 14, 2018, at 09:36, Vladimir.S wrote: > > > > On 12.01.2018 21:38, Jordan Rose wrote: >>> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution >>> > wrote: >>> Le 12 janv. 2018 à 4:44,

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 13, 2018, at 18:33, Chris Lattner wrote: > > I don’t understand why #unknown wouldn’t work in catch clauses. In the > absence of typed throws you can’t match on an enums case without the enums > base: you can’t use .foo, you have to use MyEnum.foo. > >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Is this equivalent to `default: break`? `default: fatalError()`? I think it's better to write such things explicitly. Jordan > On Jan 14, 2018, at 21:51, Tim Wang wrote: > > I would like to add a syntax sugar .casesBelow for enum value to be used in > switch

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I would like to add a syntax sugar .casesBelow for enum value to be used in switch sentence to avoid default case. enum MyEnum { case a case b case c } let myEnum: MyEnum = .a //Normally we need default case switch myEnum { case .a: print("a") default: print("other value")

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On 12.01.2018 21:38, Jordan Rose wrote: On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution > wrote: Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I don’t understand why #unknown wouldn’t work in catch clauses. In the absence of typed throws you can’t match on an enums case without the enums base: you can’t use .foo, you have to use MyEnum.foo. Similarly, catch wouldn’t allow .#unknown, it would require MyEnum.#unknown. This is

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 3:08 PM, Jordan Rose wrote: > > Okay, I went back to `unknown case` in the proposal, but mentioned Chris's > point very specifically: if the compiler emits an error, we should go with > `case #unknown` instead. (I'm very strongly in the "warning"

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 6:47 PM, Dave DeLong via swift-evolution > wrote: > > I feel like we’re talking past each other right now, so I’ll give a concrete > example: > > Let’s say MyAwesomeFramework.framework defines this enum: > > enum Access { > case none >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 6:31 PM, Jonathan Hull via swift-evolution > wrote: > > I’m definitely in the error camp, but I will go along with a warning if > everyone feels that is better. I see advantages both ways. The fact that the error approach generalizes much

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I’m definitely in the error camp, but I will go along with a warning if everyone feels that is better. Thanks, Jon > On Jan 12, 2018, at 3:08 PM, Jordan Rose via swift-evolution > wrote: > > Okay, I went back to `unknown case` in the proposal, but mentioned Chris's

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I feel like we’re talking past each other right now, so I’ll give a concrete example: Let’s say MyAwesomeFramework.framework defines this enum: enum Access { case none case readOnly case readWrite } This framework is compiled, built, and embedded in to

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 4:22 PM, Jordan Rose wrote: > > No, it's "Revision-locked imports”. Ah, yeah I can see how the rev-locked imports is a variation on “I’ve copied in this library”. > A source-breaking change is one in which updating the library at compile time >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

No, it's "Revision-locked imports". A source-breaking change is one in which updating the library at compile time will break clients at compile time. That's relevant for libraries distributed with an app as well as for libraries that are part of the OS. You may not care, but I do, and I think

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I assume you’re referring to this? Implicitly treat enums without binary compatibility concerns as @frozen Several people questioned whether it was necessary to make this distinction for libraries without binary compatibility concerns, i.e. those that are shipped with their client apps. While

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I included that, but also I again don't think that's the correct design. There's a case where that's useful, but that shouldn't be the default, and I don't think it's important enough to do in Swift 5. Jordan > On Jan 12, 2018, at 15:15, Dave DeLong wrote: > > Unless

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Unless I’m missing something, this is still missing the discussion on being able to treat all enums of internally-packaged libraries as frozen. IE, that frozen vs unfrozen is only an issue for enums that come from modules that are not packaged with your app. Dave > On Jan 12, 2018, at 4:08

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Okay, I went back to `unknown case` in the proposal, but mentioned Chris's point very specifically: if the compiler emits an error, we should go with `case #unknown` instead. (I'm very strongly in the "warning" camp, though.) I think the revised proposal is in good shape!

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Sent from my iPhone > On 12 Jan 2018, at 18:25, Jordan Rose via swift-evolution > wrote: > > > >> On Jan 11, 2018, at 23:30, Chris Lattner wrote: >> >> >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>>

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution > wrote: > >> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution >> > a écrit : >> >> On 12.01.2018 10:30, Chris Lattner via

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Sent from my iPad > On Jan 12, 2018, at 12:25 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Jan 11, 2018, at 23:30, Chris Lattner wrote: >> >> >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>>

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 11, 2018, at 23:30, Chris Lattner wrote: > > >> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >> wrote: >> >> A question about the new #unknown behavior. Is it intended to be used for >> error handling too ? >> Will

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution > a écrit : > > On 12.01.2018 10:30, Chris Lattner via swift-evolution wrote: >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>> wrote: >>> >>> A question about

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On 12.01.2018 10:30, Chris Lattner via swift-evolution wrote: On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution wrote: A question about the new #unknown behavior. Is it intended to be used for error handling too ? Will it be possible to use in catch

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution > wrote: > > A question about the new #unknown behavior. Is it intended to be used for > error handling too ? > Will it be possible to use in catch clause ? If we go with the #unknown approach, then

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

A question about the new #unknown behavior. Is it intended to be used for error handling too ? Will it be possible to use in catch clause ? > Le 12 janv. 2018 à 02:48, Howard Lovatt via swift-evolution > a écrit : > > Well if you are happy to say removal of a case

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Going that way, we can also deny addition of new members in a struct. Moreover, while you think that only Apple is interested in having binary stability, this is far to be true, and Apple OSes are not the only OS where Swift can be used. > Le 12 janv. 2018 à 02:48, Howard Lovatt via

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Well if you are happy to say removal of a case isn’t allowed, why not be symmetrical and say adding isn’t allowed and if an API would like to add cases then it needs to do so via adding an extended enum, e.g.: enum Old { case old1, old2 } enum New { case old1 // Note

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 11, 2018, at 05:08, Michel Fortin wrote: > > I think `unknown` should be a modifier for either `case` or `default`. This > would allow: > > unknown default: > unknown case _: // similar to default > unknown case (1, _): // enum in second

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Removing cases just isn’t allowed. They can be deprecated, but actually removing one is a breaking change. With a Swift enum the app will actually fail to launch with a dynamic linking error. Jordan > On Jan 10, 2018, at 21:27, Howard Lovatt wrote: > > It is a two

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I think `unknown` should be a modifier for either `case` or `default`. This would allow: unknown default: unknown case _: // similar to default unknown case (1, _): // enum in second position If the case can be reached with statically known enum values, the compiler

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Let say you have a module that declare a enum and also declare a function that take that enum as parameter and switch over it. As there is no cross module boundary, the switch don’t require #unknown or any fancy trick to be exhaustive. Now if you remove the case from the enum, any client code

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

It is a two way street though. An app compiled against an old framework might pass a deleted enum case back to the new framework that has been changed under it. Just as the app has to guard against new cases the framework has to guard against old cases! Both ends need an unknown case. --

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I am sorry, but I have to disagree here. Having two separate proposals would make it highly more likely that one thing is done and the other one postponed and postponed until it seems no longer relevant in the grand scheme of things... first we lost labels in callbacks / stores functions (has

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 10, 2018, at 10:10 AM, Jordan Rose wrote: > >>> >>> - Matching known cases is a feature, not a limitation, to avoid existing >>> code changing meaning when you recompile. I'll admit that's not the >>> strongest motivation, though, since other things can change

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Remember, the goal here is to support both binary and source compatibility. An existing app might be using the enum case that you're trying to remove, but there's no chance that an existing app is using an enum case that you're trying to add. Jordan > On Jan 10, 2018, at 16:34, Howard Lovatt

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

If an enum isn’t final; then what’s the difference in deleting as opposed to adding? -- Howard. > On 10 Jan 2018, at 4:13 pm, Jean-Daniel wrote: > > > >> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution >> a écrit : >> >> Two

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

on Wed, 10 Jan 2018 07:12:27 + Antoine Cœur wrote: > > And what about, as an alternative: > > case (_, #unknown): … matches any int and any unknown enum case ... > case _: … matches anything ... > > Then it clearly goes the "pattern matching" way. > this will be

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution > a écrit : > > Two points: > > 1. I like Chris’s suggestion of #unknown and in particular that it is > distinct from default. > > 2. All the discussion is about a framework adding a case, what about

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Two points: 1. I like Chris’s suggestion of #unknown and in particular that it is distinct from default. 2. All the discussion is about a framework adding a case, what about when a framework deletes a case? -- Howard. > On 10 Jan 2018, at 1:41 pm, Dave DeLong via swift-evolution >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 10, 2018, at 1:29 PM, Dave DeLong via swift-evolution > wrote: > > > >> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution >> > wrote: >> >> That said, it sounds like people

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution > wrote: > > >>> That said, it sounds like people are happier with `case #unknown` than >>> `unknown case`, and that leaves things a little more consistent if we ever >>> do expand it to other pattern

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 10, 2018, at 12:04, Jose Cheyo Jimenez via swift-evolution > wrote: > > > > On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner > wrote: > On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

>> That said, it sounds like people are happier with `case #unknown` than >> `unknown case`, and that leaves things a little more consistent if we ever >> do expand it to other pattern positions, so I'll change the proposal >> revision to use that spelling. (And if anyone comes up with a nicer

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner wrote: > On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez > wrote: > > Hi Chris, > > > > This is great. Thanks for spending time on this! I am in favor of `case > #unknown` to only match unknown cases. > > >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 9, 2018, at 22:17, Chris Lattner wrote: > > On Jan 9, 2018, at 4:46 PM, Jordan Rose > wrote: >> Thanks for writing this up, Chris! I addressed the idea of making this an >> arbitrary pattern in the revised

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 9, 2018, at 21:39, Brent Royal-Gordon wrote: > > > >> On Jan 9, 2018, at 4:46 PM, Jordan Rose via swift-evolution >> > wrote: >> >> - FWIW I can't actually think of a use case for using this with

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

And what about, as an alternative: case (_, #unknown): … matches any int and any unknown enum case ... case _: … matches anything ... Then it clearly goes the "pattern matching" way. Le mer. 10 janv. 2018 à 14:17, Chris Lattner via swift-evolution < swift-evolution@swift.org> a écrit : > On

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On Jan 9, 2018, at 4:46 PM, Jordan Rose wrote: > Thanks for writing this up, Chris! I addressed the idea of making this an > arbitrary pattern in the revised proposal >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez wrote: > Hi Chris, > > This is great. Thanks for spending time on this! I am in favor of `case > #unknown` to only match unknown cases. > > 1) Would #uknown be available to RawRepresentable structs? I haven’t considered

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On Jan 9, 2018, at 12:27 PM, Vladimir.S wrote: >> 2) Swift also has other facilities for pattern matching, including ‘if >> case’. Making switch inconsistent with them is not great. >> 3) As pitched, “unknown case” will match *known* cases too, which is (in my >> opinion :-)

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I'm not in favor to distinguish #unknown and #known, as it may lead to surprises, like something that previously was unknown becomes known on a newer iOS version for instance. And version-dependant code is clearer if solely handled by the `@available()` syntax. I like the new pattern matching

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 9, 2018, at 4:46 PM, Jordan Rose via swift-evolution > wrote: > > - FWIW I can't actually think of a use case for using this with `if case` or > anything else. I'm not against it, but I don't know why you would ever do it, > just like I don't know why you

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution > wrote: > > The mega-thread about SE-0192 is a bit large, and I’d like to talk about one > specific point. In the review conversation, there has been significant > objection to the idea of requiring a

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Hi Chris, This is great. Thanks for spending time on this! I am in favor of `case #unknown` to only match unknown cases. 1) Would #uknown be available to RawRepresentable structs? 2) How is the #uknown pattern accomplished? Are you suggesting to capture all the compile time known cases so you

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Something like `#unknown` or `#undiscovered` in the pattern matching syntax makes complete sense. -Richard > On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution > wrote: > > The mega-thread about SE-0192 is a bit large, and I’d like to talk about one >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Hi Chris, thank you for the new idea! FWIW, after first reading, it looks like more elegant solution than "unknown case" in initial proposal. Swift's enums deserve powerful and flexible solution! I really like the syntax of switch val { case .one: ... case .two: ... case #unknown: ... }