> 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.


swift-evolution mailing list

Reply via email to