> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution > <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. Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
