> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution
> <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> 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.
--
Michel Fortin
https://michelf.ca
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
