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") } //Now use syntax sugar switch myEnum.casesBelow { case .a: print("a") } This would look more intuitive to me than other solutions but I am not sure how much effort we need for this. On Mon, Jan 15, 2018 at 4:36 AM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > > > On 12.01.2018 21:38, Jordan Rose wrote: > > > > > >> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution < > swift-evolution@swift.org > >> <mailto:swift-evolution@swift.org>> wrote: > >> > >>> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution < > swift-evolution@swift.org > >>> <mailto:swift-evolution@swift.org>> 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 < > swift-evolution@swift.org > >>>>> <mailto:swift-evolution@swift.org>> 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 yes of course it will work > in catch clauses. They are patterns, so it > >>>> naturally falls out. > >>>> If we go with the “unknown default:” / “unknown case:" approach, > then no, this has nothing to do with error handling. > >>>> IMO, this pivots on the desired semantics for “unknown cases in > enums”: if you intentionally try to match on this, > >>>> do we get a warning or error if you don’t handle all the cases? If > we can get to consensus on that point, then the > >>>> design is pretty obvious IMO. > >>> > >>> For me the other question is what "all the cases" means for enum with > private cases(if we'll have them). I.e. if > >>> switch contains all the "public" cases of frozen enum - does this mean > "all the cases" were processed? As I > >>> understand, the answer is no, because we *can* have 'private' case > value here and so we need to react to this. How > >>> switch will look in this case? > >>> > >>> switch frozenEnumWithPrivateCases { > >>> case .one: .. > >>> case .two: .. > >>> unknown default: .. // or 'case #unknown:' depending on our > decision, or 'unknown case:' etc > >>> } > >>> ? > >>> But then such switch looks exactly as switch for non-frozen enum > value, no? It looks like we are reacting on future > >>> new cases, while enum is frozen. > >>> > >>> Moreover. How the switch for non-frozed enum with private cases should > looks like? > >>> > >>> switch nonfrozenEnumWithPrivateCases { > >>> case .one: .. > >>> case .two: .. > >>> unknown default: .. // or 'case #unknown:' depending on our > decision, or 'unknown case:' etc > >>> } > >>> ? But then, is that 'unknown default' for reacting on "future" cases > we didn't know about during the compilation OR > >>> it is for reacting on private cases? > >>> > >>> Or the main idea that we don't want to separate "future" cases and > "private" cases? > >> > >> I think treating both as the same thing is the right idea. You also > need to handle "future private" cases and "private > >> cases that become public in the future". These are all unknown cases in > the context of the switch. > >> > >> So an enum with private cases can't be switched exhaustively outside of > its module. Thus, @frozen would need to forbid > >> private cases... or we need @exhaustive to forbid private cases so they > can be allowed by @frozen. > > > > As mentioned in "Future directions", my recommendation to anyone > planning to write a proposal for non-public cases is to > > go with the former, which would keep it from infecting the design. > > > > Thank you for the comment! > From proposal: > "Were such a proposal to be written, I advise that a frozen enum not be > permitted to have non-public cases." > > OK. Seems logically for frozen enum(imported from another module) to not > have non-public cases, as such cases most > likely will be added later during the evaluation of the library(external > module) - so such enum should not be frozen then. > > I'd like to discuss how current decision will fit into the (possible) > future 'private cases' in enum. > > 1. Non-frozen enum with private cases in the same module. > > It seems like we'll need to write > switch val { > case .one : .. > case .two : .. > unknown default: .. // for private cases, even 'val' can't have 'future' > cases > } > > So, 'unknown default' will mean not just 'future cases', but 'future cases > and private cases'. > > 2. Non-frozen enum with private cases in another module. > > In this case, if we want exhaustive switch, we need to use 'unknown > default'. But I feel like known but private cases > are not the same as future public cases for the 'consumer' of that enum, > no? > > I mean, when making a decision what to do inside 'unknown default' - isn't > it important to know what is the "event" - > new public case or private(even "known") case? I'm thinking about > something like this: > > let val = getSomeNonFrozenEnumResultFromLibrary() > switch val { > case .one : ... // process the val on our side > case .two : ... // process the val on our side > > private default : sendValueBackToLibraryToProcess(val) // not > interested, calling some special handler > future default : .. // somehow react on important new case introduced > in library. for example, show "please update > the app" for the user and cancels the current operation > } > > I don't think we need to think about "future private" cases, as we don't > have access to them in any case, so current and > future private cases are not distinguishable for us. > > I'm not sure if we should distinct future cases and private cases on > 'switch' side, but I think we should discuss this > now for taking a correct decision regarding 'unknown default' etc. > > P.S. FWIW I agree with Chris Lattner that 'unknown default' fits into > Swift syntax and mental model much better than > 'unknown case'. This handler is for default reacting on _number_ of > unknown cases, not for reacting on some _specific_ > case, like other 'case xxx:' handlers. Are we going to discuss this and > select the better name? Or most of us not agree > that 'unknown case' is the best? > > Vladimir. > > > Jordan > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution