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 <shenghai.w...@bigtincan.com> wrote:
>
> 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 <mailto: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>
> >> <mailto: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>
> >>> <mailto: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>
> >>>>> <mailto: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 <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
