<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Is this equivalent to `default: break`? `default: fatalError()`? I think it's better to write such things explicitly.<div class=""><br class=""></div><div class="">Jordan<br class=""><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 14, 2018, at 21:51, Tim Wang <<a href="mailto:shenghai.wang@bigtincan.com" class="">shenghai.wang@bigtincan.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I would like to add a syntax sugar .casesBelow for enum value to be used in switch sentence to avoid default case.<div class=""><br class=""></div><div class="">enum MyEnum {</div><div class=""> case a</div><div class=""> case b</div><div class=""> case c</div><div class="">}</div><div class=""><br class=""></div><div class="">let myEnum: MyEnum = .a</div><div class=""><br class=""></div><div class="">//Normally we need default case</div><div class="">switch myEnum {</div><div class=""> case .a: print("a")</div><div class=""> default: print("other value")</div><div class="">}</div><div class=""><br class=""></div><div class="">//Now use syntax sugar</div><div class=""><div class="">switch myEnum.casesBelow {</div><div class=""> case .a: print("a")</div><div class="">}<br class=""></div></div><div class=""><br class=""><div class=""><br class=""></div><div class="">This would look more intuitive to me than other solutions but I am not sure how much effort we need for this.<div class=""><br class=""></div><div class=""><br class=""></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jan 15, 2018 at 4:36 AM Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
<br class="">
On 12.01.2018 21:38, Jordan Rose wrote:<br class="">
><br class="">
><br class="">
>> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>> wrote:<br class="">
>><br class="">
>>> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
>>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>> a écrit :<br class="">
>>><br class="">
>>> On 12.01.2018 10:30, Chris Lattner via swift-evolution wrote:<br class="">
>>>>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
>>>>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>> wrote:<br class="">
>>>>><br class="">
>>>>> A question about the new #unknown behavior. Is it intended to be used for error handling too ?<br class="">
>>>>> Will it be possible to use in catch clause ?<br class="">
>>>> If we go with the #unknown approach, then yes of course it will work in catch clauses. They are patterns, so it<br class="">
>>>> naturally falls out.<br class="">
>>>> If we go with the “unknown default:” / “unknown case:" approach, then no, this has nothing to do with error handling.<br class="">
>>>> IMO, this pivots on the desired semantics for “unknown cases in enums”: if you intentionally try to match on this,<br class="">
>>>> 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<br class="">
>>>> design is pretty obvious IMO.<br class="">
>>><br class="">
>>> For me the other question is what "all the cases" means for enum with private cases(if we'll have them). I.e. if<br class="">
>>> switch contains all the "public" cases of frozen enum - does this mean "all the cases" were processed? As I<br class="">
>>> understand, the answer is no, because we *can* have 'private' case value here and so we need to react to this. How<br class="">
>>> switch will look in this case?<br class="">
>>><br class="">
>>> switch frozenEnumWithPrivateCases {<br class="">
>>> case .one: ..<br class="">
>>> case .two: ..<br class="">
>>> unknown default: .. // or 'case #unknown:' depending on our decision, or 'unknown case:' etc<br class="">
>>> }<br class="">
>>> ?<br class="">
>>> But then such switch looks exactly as switch for non-frozen enum value, no? It looks like we are reacting on future<br class="">
>>> new cases, while enum is frozen.<br class="">
>>><br class="">
>>> Moreover. How the switch for non-frozed enum with private cases should looks like?<br class="">
>>><br class="">
>>> switch nonfrozenEnumWithPrivateCases {<br class="">
>>> case .one: ..<br class="">
>>> case .two: ..<br class="">
>>> unknown default: .. // or 'case #unknown:' depending on our decision, or 'unknown case:' etc<br class="">
>>> }<br class="">
>>> ? But then, is that 'unknown default' for reacting on "future" cases we didn't know about during the compilation OR<br class="">
>>> it is for reacting on private cases?<br class="">
>>><br class="">
>>> Or the main idea that we don't want to separate "future" cases and "private" cases?<br class="">
>><br class="">
>> I think treating both as the same thing is the right idea. You also need to handle "future private" cases and "private<br class="">
>> cases that become public in the future". These are all unknown cases in the context of the switch.<br class="">
>><br class="">
>> So an enum with private cases can't be switched exhaustively outside of its module. Thus, @frozen would need to forbid<br class="">
>> private cases... or we need @exhaustive to forbid private cases so they can be allowed by @frozen.<br class="">
><br class="">
> As mentioned in "Future directions", my recommendation to anyone planning to write a proposal for non-public cases is to<br class="">
> go with the former, which would keep it from infecting the design.<br class="">
><br class="">
<br class="">
Thank you for the comment!<br class="">
From proposal:<br class="">
"Were such a proposal to be written, I advise that a frozen enum not be permitted to have non-public cases."<br class="">
<br class="">
OK. Seems logically for frozen enum(imported from another module) to not have non-public cases, as such cases most<br class="">
likely will be added later during the evaluation of the library(external module) - so such enum should not be frozen then.<br class="">
<br class="">
I'd like to discuss how current decision will fit into the (possible) future 'private cases' in enum.<br class="">
<br class="">
1. Non-frozen enum with private cases in the same module.<br class="">
<br class="">
It seems like we'll need to write<br class="">
switch val {<br class="">
case .one : ..<br class="">
case .two : ..<br class="">
unknown default: .. // for private cases, even 'val' can't have 'future' cases<br class="">
}<br class="">
<br class="">
So, 'unknown default' will mean not just 'future cases', but 'future cases and private cases'.<br class="">
<br class="">
2. Non-frozen enum with private cases in another module.<br class="">
<br class="">
In this case, if we want exhaustive switch, we need to use 'unknown default'. But I feel like known but private cases<br class="">
are not the same as future public cases for the 'consumer' of that enum, no?<br class="">
<br class="">
I mean, when making a decision what to do inside 'unknown default' - isn't it important to know what is the "event" -<br class="">
new public case or private(even "known") case? I'm thinking about something like this:<br class="">
<br class="">
let val = getSomeNonFrozenEnumResultFromLibrary()<br class="">
switch val {<br class="">
case .one : ... // process the val on our side<br class="">
case .two : ... // process the val on our side<br class="">
<br class="">
private default : sendValueBackToLibraryToProcess(val) // not interested, calling some special handler<br class="">
future default : .. // somehow react on important new case introduced in library. for example, show "please update<br class="">
the app" for the user and cancels the current operation<br class="">
}<br class="">
<br class="">
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<br class="">
future private cases are not distinguishable for us.<br class="">
<br class="">
I'm not sure if we should distinct future cases and private cases on 'switch' side, but I think we should discuss this<br class="">
now for taking a correct decision regarding 'unknown default' etc.<br class="">
<br class="">
P.S. FWIW I agree with Chris Lattner that 'unknown default' fits into Swift syntax and mental model much better than<br class="">
'unknown case'. This handler is for default reacting on _number_ of unknown cases, not for reacting on some _specific_<br class="">
case, like other 'case xxx:' handlers. Are we going to discuss this and select the better name? Or most of us not agree<br class="">
that 'unknown case' is the best?<br class="">
<br class="">
Vladimir.<br class="">
<br class="">
> Jordan<br class="">
><br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>