Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

> On Jan 17, 2018, at 4:19 PM, Jordan Rose  wrote:
>>> 
>>> The parser has fairly general support for declmodifiers, and my proposal 
>>> fits directly into that.  The only extension is that ‘default’ isn’t a 
>>> decl, and I don’t think we have a statement modifier yet.  That said, we’ve 
>>> always planned to have them when the need arose.
>> 
>> ‘case’ isn’t a decl in switches either. Nor is it a statement, the way 
>> things are modeled today.
> 
> Bleah, sorry, I forgot that it is a statement at the moment. But I don't 
> think it needs to be modeled as a statement attribute/modifier. A flag on 
> CaseStmt is fine.

DeclModifiers are a syntax/parser thing, not a representational concept in the 
AST.  Storing it as a bit would be fine, I’d also prefer that.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 17, 2018, at 14:42, Jordan Rose  wrote:
> 
> 
> 
>> On Jan 17, 2018, at 14:41, Chris Lattner > > wrote:
>> 
>>> On Jan 16, 2018, at 10:24 AM, Jordan Rose >> > wrote:
> On Jan 12, 2018, at 3:08 PM, Jordan Rose  > wrote:
> 
> Okay, I went back to `unknown case` in the proposal, but mentioned 
> Chris's point very specifically: if the compiler emits an error, we 
> should go with `case #unknown` instead. (I'm very strongly in the 
> "warning" camp, though.)
 
 Thanks!
 
 Out of curiosity, why not “unknown default:”?  The “warning” behavior is a 
 customization of default, so this seems like a more logical model.  It 
 also fits into the existing Swift grammar, unlike “unknown case:” which 
 requires adding a new special case production.
>>> 
>>> I'm not sure how this fits more into the existing grammar. Both of them 
>>> require custom parsing with one token's worth of lookahead. You're right 
>>> that they suggest different natural modelings in the AST, but that's an 
>>> implementation detail.
>> 
>> The parser has fairly general support for declmodifiers, and my proposal 
>> fits directly into that.  The only extension is that ‘default’ isn’t a decl, 
>> and I don’t think we have a statement modifier yet.  That said, we’ve always 
>> planned to have them when the need arose.
> 
> ‘case’ isn’t a decl in switches either. Nor is it a statement, the way things 
> are modeled today.

Bleah, sorry, I forgot that it is a statement at the moment. But I don't think 
it needs to be modeled as a statement attribute/modifier. A flag on CaseStmt is 
fine.

Jordan

> But this is all implementation detail; it’s not interesting to discuss that.
> 
> Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 17, 2018, at 14:41, Chris Lattner  wrote:
> 
>> On Jan 16, 2018, at 10:24 AM, Jordan Rose > > wrote:
 On Jan 12, 2018, at 3:08 PM, Jordan Rose > wrote:
 
 Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
 point very specifically: if the compiler emits an error, we should go with 
 `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
>>> 
>>> Thanks!
>>> 
>>> Out of curiosity, why not “unknown default:”?  The “warning” behavior is a 
>>> customization of default, so this seems like a more logical model.  It also 
>>> fits into the existing Swift grammar, unlike “unknown case:” which requires 
>>> adding a new special case production.
>> 
>> I'm not sure how this fits more into the existing grammar. Both of them 
>> require custom parsing with one token's worth of lookahead. You're right 
>> that they suggest different natural modelings in the AST, but that's an 
>> implementation detail.
> 
> The parser has fairly general support for declmodifiers, and my proposal fits 
> directly into that.  The only extension is that ‘default’ isn’t a decl, and I 
> don’t think we have a statement modifier yet.  That said, we’ve always 
> planned to have them when the need arose.

‘case’ isn’t a decl in switches either. Nor is it a statement, the way things 
are modeled today. But this is all implementation detail; it’s not interesting 
to discuss that.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

> On Jan 16, 2018, at 10:24 AM, Jordan Rose  wrote:
>>> On Jan 12, 2018, at 3:08 PM, Jordan Rose >> > wrote:
>>> 
>>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
>>> point very specifically: if the compiler emits an error, we should go with 
>>> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
>> 
>> Thanks!
>> 
>> Out of curiosity, why not “unknown default:”?  The “warning” behavior is a 
>> customization of default, so this seems like a more logical model.  It also 
>> fits into the existing Swift grammar, unlike “unknown case:” which requires 
>> adding a new special case production.
> 
> I'm not sure how this fits more into the existing grammar. Both of them 
> require custom parsing with one token's worth of lookahead. You're right that 
> they suggest different natural modelings in the AST, but that's an 
> implementation detail.

The parser has fairly general support for declmodifiers, and my proposal fits 
directly into that.  The only extension is that ‘default’ isn’t a decl, and I 
don’t think we have a statement modifier yet.  That said, we’ve always planned 
to have them when the need arose.

-Chris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 14, 2018, at 09:36, Vladimir.S  wrote:
> 
> 
> 
> On 12.01.2018 21:38, Jordan Rose wrote:
>>> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution 
>>> > wrote:
>>> 
 Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution 
 > 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 
>> > 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'.

Interesting. I didn't think about that; in the original proposal without any 
warnings, you just had to use 'default'. But it does make sense, and whoever 
proposes private cases will have to mention that.



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

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 13, 2018, at 18:33, Chris Lattner  wrote:
> 
> I don’t understand why #unknown wouldn’t work in catch clauses.  In the 
> absence of typed throws you can’t match on an enums case without the enums 
> base:  you can’t use .foo, you have to use MyEnum.foo.
> 
> Similarly, catch wouldn’t allow .#unknown, it would require MyEnum.#unknown.  
> This is perfectly well defined and just falls out of the model.

I did not think about this. You're right, we could allow that syntax. We don't 
currently have any hash-prefixed constructs that aren't "top-level", but that's 
not a rule or anything.

Jordan

> 
> That said, I agree that the issue of source dependencies that might use this 
> is a significant problem.  IMO, that argues strongly for “unknown default:” 
> producing a warning.
> 
> -Chris
> 
>> On Jan 12, 2018, at 10:49 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jan 12, 2018, at 3:08 PM, Jordan Rose  wrote:
>>> 
>>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
>>> point very specifically: if the compiler emits an error, we should go with 
>>> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
>> 
>> Thanks!
>> 
>> Out of curiosity, why not “unknown default:”?  The “warning” behavior is a 
>> customization of default, so this seems like a more logical model.  It also 
>> fits into the existing Swift grammar, unlike “unknown case:” which requires 
>> adding a new special case production.
>> 
>> -Chris
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

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  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 
> > wrote:
> 
> 
> On 12.01.2018 21:38, Jordan Rose wrote:
> >
> >
> >> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution 
> >> 
> >> >> 
> >> wrote:
> >>
> >>> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution 
> >>> 
> >>> >> 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 
> > 
> > >> 
> > 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 

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Tim Wang via swift-evolution]

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

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Vladimir.S via swift-evolution]

On 12.01.2018 21:38, Jordan Rose wrote:



On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution > wrote:


Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution > 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 > 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 

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

I don’t understand why #unknown wouldn’t work in catch clauses.  In the absence 
of typed throws you can’t match on an enums case without the enums base:  you 
can’t use .foo, you have to use MyEnum.foo.

Similarly, catch wouldn’t allow .#unknown, it would require MyEnum.#unknown.  
This is perfectly well defined and just falls out of the model.

That said, I agree that the issue of source dependencies that might use this is 
a significant problem.  IMO, that argues strongly for “unknown default:” 
producing a warning.

-Chris

> On Jan 12, 2018, at 10:49 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jan 12, 2018, at 3:08 PM, Jordan Rose  wrote:
>> 
>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
>> point very specifically: if the compiler emits an error, we should go with 
>> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
> 
> Thanks!
> 
> Out of curiosity, why not “unknown default:”?  The “warning” behavior is a 
> customization of default, so this seems like a more logical model.  It also 
> fits into the existing Swift grammar, unlike “unknown case:” which requires 
> adding a new special case production.
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

> On Jan 12, 2018, at 3:08 PM, Jordan Rose  wrote:
> 
> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
> point very specifically: if the compiler emits an error, we should go with 
> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)

Thanks!

Out of curiosity, why not “unknown default:”?  The “warning” behavior is a 
customization of default, so this seems like a more logical model.  It also 
fits into the existing Swift grammar, unlike “unknown case:” which requires 
adding a new special case production.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[John McCall via swift-evolution]

> On Jan 12, 2018, at 6:47 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> I feel like we’re talking past each other right now, so I’ll give a concrete 
> example:
> 
> Let’s say MyAwesomeFramework.framework defines this enum:
> 
> enum Access {
>   case none
>   case readOnly
>   case readWrite
> }
> 
> This framework is compiled, built, and embedded in to 
> MyAwesomeApp.app/Frameworks.
> 
> Somewhere in MyAwesomeApp, I switch on the access of a thing:
> 
> switch aThing.access {
>   case .none: break
>   case .readOnly: print(“I can read”)
>   case .readWrite: print(“I can write”)
> }
> 
> Let’s here observe some things:
> 
> 1️⃣ the enum “Access” is *not* declared as frozen, because it might get a new 
> case in the future (such as “writeOnly”)
> 2️⃣ the switch on an Access value is exhaustive
> 3️⃣ under the proposal, I’m going to get a warning on the switch because 
> Access is not frozen. That warning will tell me to add “unknown case:”
> 
> This is the problem I’m talking about. The warning I’ll get on the switch is 
> technically correct (I’m switching on a non-frozen enum), but semantically 
> incorrect (it’s ok because the framework CANNOT introduce a new case without 
> recompilation of the switch statement, because they are packaged together). 
> The compiler will tell me to add an unknown case statement to the switch when 
> it will be completely unnecessary. Since MyAwesomeFramework.framework is 
> embedded in my app, there is no binary compatibility concern here, and I will 
> never come across an unknown case.
> 
> I think this false positive is going to be very common, because lots of 
> people embed frameworks in their apps, and those frameworks declare enums. 
> Until the frameworks are updated to freeze the enums, the app authors will be 
> forced to add “unknown case” statements to their switches for places where it 
> is entirely unnecessary. (This brings up the question: does this proposal 
> include a fixit to remove an “unknown case” statement from switches where 
> it’s unnecessary?)
> 
> So, what I’m asking for is a part in the proposal (likely under “Future 
> Directions”) where you acknowledge this problem (the “false positive problem 
> for embedded modules”) and list it as something we’d like to solve in the 
> future.

I agree that it's important to discuss this in the proposal.

I think the point that Jordan is trying to make is that this kind of resilience 
problem can come up as a source-compatibility issue, not just a 
binary-compatibility issue.  Of course an app can be version-locked to its 
non-OS dependencies and nobody will care.  However, it's problematic for a 
library to be version-locked to its dependencies even if both the library and 
its dependencies are only ever distributed as source: you ought to be able to 
upgrade the dependencies without having to revise all the dependent libraries.  
If our library ecosystem doesn't let you pull a new version of BaseLib without 
simultaneously pulling new versions of everything else you use that requires 
BaseLib — or, alternatively, hand-fixing them all yourself if that library 
hasn't gotten updated yet — that's a pretty frustrating experience.

Conversely, an app ought to be able to be version-locked to its non-OS 
dependencies whether they're binaries or source.  So this really has almost 
nothing to do with binary vs. source distribution and everything to do with 
whether version-locking makes sense for a specific project.

John.

> 
> Dave
> 
>> On Jan 12, 2018, at 4:27 PM, Dave DeLong via swift-evolution 
>> > wrote:
>> 
>>> On Jan 12, 2018, at 4:22 PM, Jordan Rose >> > wrote:
>>> 
>>> No, it's "Revision-locked imports”.
>> 
>> Ah, yeah I can see how the rev-locked imports is a variation on “I’ve copied 
>> in this library”.
>> 
>>> A source-breaking change is one in which updating the library at compile 
>>> time will break clients at compile time. That's relevant for libraries 
>>> distributed with an app as well as for libraries that are part of the OS. 
>>> You may not care, but I do, and I think other package authors will too.
>> 
>> ??? Of course I care about getting warnings when I’ve chosen to update a 
>> dependency. Where did I ever imply otherwise?
>> 
>> What I’m saying is that if I’m embedding such a library in my app *now* and 
>> I’m importing it *now*, I shouldn’t get a warning about handling unknown 
>> cases off non-frozen enums *now*. 
>> 
>> And if I am going to see such warnings now, then the document needs to 
>> include how those “false positives” will be eliminated in the future.
>> 
>> Dave
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Matthew Johnson via swift-evolution]

> On Jan 12, 2018, at 6:31 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I’m definitely in the error camp, but I will go along with a warning if 
> everyone feels that is better.

I see advantages both ways.  The fact that the error approach generalizes much 
cleaner is definitely a plus.  

The primary downside to that approach is losing the ability to rebuild with the 
same version of a source dependency that has used #unkown when matching a 
non-frozen enum vended by a common dependency to which a case has been added 
since the source dependency was written.  Requiring this behavior can be viewed 
as a pretty significant downside.  It tightens the coupling between versions of 
dependencies.  This can make it difficult to update dependencies in a large 
project.  The warning approach allows people to opt-in to this behavior by 
treating warnings as errors without requiring everyone to make the same 
tradeoff.

It’s really a tough tradeoff.

> 
> Thanks,
> Jon
> 
>> On Jan 12, 2018, at 3:08 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
>> point very specifically: if the compiler emits an error, we should go with 
>> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
>> 
>> I think the revised proposal is in good shape! 
>> (https://github.com/apple/swift-evolution/pull/777) I think I've addressed 
>> everyone's feedback either in the proposal or on-list, if not necessarily 
>> convinced them. If there are no other major comments I'll let Ted know that 
>> it's ready to re-run on Monday.
>> 
>> Jordan
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Rex Fenley via swift-evolution]

Hey Jordan, coming into this a bit late, but it seems like `case #unknown`
is the more flexible syntax regardless of warning or error. If typed errors
are added then it would fall cleanly into catch pattern matching as well it
sounds like. Any thoughts there?

And for the record I'm slightly in favor of an error on unknown matches.
I'm just not sure that breaking source compatibility has been an issue with
enums thus far. It'd be my own preference to throw an error if I intend for
a type to be exhaustively matched, though I can definitely be ok with just
a warning too.

Okay, I went back to `unknown case` in the proposal, but mentioned Chris's
> point very specifically: if the compiler emits an error, we should go with
> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)



I think the revised proposal is in good shape! (
> https://github.com/apple/swift-evolution/pull/777) I think I've addressed
> everyone's feedback either in the proposal or on-list, if not necessarily
> convinced them. If there are no other major comments I'll let Ted know that
> it's ready to re-run on Monday. Jordan


-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jonathan Hull via swift-evolution]

I’m definitely in the error camp, but I will go along with a warning if 
everyone feels that is better.

Thanks,
Jon

> On Jan 12, 2018, at 3:08 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
> point very specifically: if the compiler emits an error, we should go with 
> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
> 
> I think the revised proposal is in good shape! 
> (https://github.com/apple/swift-evolution/pull/777) I think I've addressed 
> everyone's feedback either in the proposal or on-list, if not necessarily 
> convinced them. If there are no other major comments I'll let Ted know that 
> it's ready to re-run on Monday.
> 
> Jordan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Dave DeLong via swift-evolution]

I feel like we’re talking past each other right now, so I’ll give a concrete 
example:

Let’s say MyAwesomeFramework.framework defines this enum:

enum Access {
case none
case readOnly
case readWrite
}

This framework is compiled, built, and embedded in to 
MyAwesomeApp.app/Frameworks.

Somewhere in MyAwesomeApp, I switch on the access of a thing:

switch aThing.access {
case .none: break
case .readOnly: print(“I can read”)
case .readWrite: print(“I can write”)
}

Let’s here observe some things:

1️⃣ the enum “Access” is *not* declared as frozen, because it might get a new 
case in the future (such as “writeOnly”)
2️⃣ the switch on an Access value is exhaustive
3️⃣ under the proposal, I’m going to get a warning on the switch because Access 
is not frozen. That warning will tell me to add “unknown case:”

This is the problem I’m talking about. The warning I’ll get on the switch is 
technically correct (I’m switching on a non-frozen enum), but semantically 
incorrect (it’s ok because the framework CANNOT introduce a new case without 
recompilation of the switch statement, because they are packaged together). The 
compiler will tell me to add an unknown case statement to the switch when it 
will be completely unnecessary. Since MyAwesomeFramework.framework is embedded 
in my app, there is no binary compatibility concern here, and I will never come 
across an unknown case.

I think this false positive is going to be very common, because lots of people 
embed frameworks in their apps, and those frameworks declare enums. Until the 
frameworks are updated to freeze the enums, the app authors will be forced to 
add “unknown case” statements to their switches for places where it is entirely 
unnecessary. (This brings up the question: does this proposal include a fixit 
to remove an “unknown case” statement from switches where it’s unnecessary?)

So, what I’m asking for is a part in the proposal (likely under “Future 
Directions”) where you acknowledge this problem (the “false positive problem 
for embedded modules”) and list it as something we’d like to solve in the 
future.

Dave

> On Jan 12, 2018, at 4:27 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
>> On Jan 12, 2018, at 4:22 PM, Jordan Rose > > wrote:
>> 
>> No, it's "Revision-locked imports”.
> 
> Ah, yeah I can see how the rev-locked imports is a variation on “I’ve copied 
> in this library”.
> 
>> A source-breaking change is one in which updating the library at compile 
>> time will break clients at compile time. That's relevant for libraries 
>> distributed with an app as well as for libraries that are part of the OS. 
>> You may not care, but I do, and I think other package authors will too.
> 
> ??? Of course I care about getting warnings when I’ve chosen to update a 
> dependency. Where did I ever imply otherwise?
> 
> What I’m saying is that if I’m embedding such a library in my app *now* and 
> I’m importing it *now*, I shouldn’t get a warning about handling unknown 
> cases off non-frozen enums *now*. 
> 
> And if I am going to see such warnings now, then the document needs to 
> include how those “false positives” will be eliminated in the future.
> 
> Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Dave DeLong via swift-evolution]

> On Jan 12, 2018, at 4:22 PM, Jordan Rose  wrote:
> 
> No, it's "Revision-locked imports”.

Ah, yeah I can see how the rev-locked imports is a variation on “I’ve copied in 
this library”.

> A source-breaking change is one in which updating the library at compile time 
> will break clients at compile time. That's relevant for libraries distributed 
> with an app as well as for libraries that are part of the OS. You may not 
> care, but I do, and I think other package authors will too.

??? Of course I care about getting warnings when I’ve chosen to update a 
dependency. Where did I ever imply otherwise?

What I’m saying is that if I’m embedding such a library in my app *now* and I’m 
importing it *now*, I shouldn’t get a warning about handling unknown cases off 
non-frozen enums *now*. 

And if I am going to see such warnings now, then the document needs to include 
how those “false positives” will be eliminated in the future.

Dave___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

No, it's "Revision-locked imports".

A source-breaking change is one in which updating the library at compile time 
will break clients at compile time. That's relevant for libraries distributed 
with an app as well as for libraries that are part of the OS. You may not care, 
but I do, and I think other package authors will too.

Jordan


> On Jan 12, 2018, at 15:20, Dave DeLong  wrote:
> 
> I assume you’re referring to this?
> Implicitly treat enums without binary compatibility concerns as @frozen
> 
> Several people questioned whether it was necessary to make this distinction 
> for libraries without binary compatibility concerns, i.e. those that are 
> shipped with their client apps. While there may be a need to do something to 
> handle enums shipped with Apple's OS SDKs, it's arguable whether this is 
> worth it for "source libraries", such as SwiftPM packages.
> 
> This question can be rephrased as "is adding a case to an enum a 
> source-breaking change?" 
> 
> 
> I don’t follow on how this is a source-breaking change.
> 
> Let’s say I’m writing an app “A” that embeds a module “M”, which defines and 
> enum “E”.
> 
> If E is frozen, the everything’s fine and all is well.
> If E is *not* frozen, then the compiler is going to force me to put in an 
> “unknown case”, because it has falsely concluded that E may change out from 
> underneath my app.
> 
> The will be a mistake on the compiler’s part. I do not need to include the 
> “unknown case” handler while enumerating on E, because there is no 
> possibility of ever getting an unknown enum value from M, because it is 
> statically copied in to my app and will never change.
> 
> Dave
> 
>> On Jan 12, 2018, at 4:16 PM, Jordan Rose > > wrote:
>> 
>> I included that, but also I again don't think that's the correct design. 
>> There's a case where that's useful, but that shouldn't be the default, and I 
>> don't think it's important enough to do in Swift 5.
>> 
>> Jordan
>> 
>> 
>>> On Jan 12, 2018, at 15:15, Dave DeLong >> > wrote:
>>> 
>>> Unless I’m missing something, this is still missing the discussion on being 
>>> able to treat all enums of internally-packaged libraries as frozen.
>>> 
>>> IE, that frozen vs unfrozen is only an issue for enums that come from 
>>> modules that are not packaged with your app.
>>> 
>>> Dave
>>> 
 On Jan 12, 2018, at 4:08 PM, Jordan Rose via swift-evolution 
 > wrote:
 
 Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
 point very specifically: if the compiler emits an error, we should go with 
 `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
 
 I think the revised proposal is in good shape! 
 (https://github.com/apple/swift-evolution/pull/777 
 ) I think I've 
 addressed everyone's feedback either in the proposal or on-list, if not 
 necessarily convinced them. If there are no other major comments I'll let 
 Ted know that it's ready to re-run on Monday.
 
 Jordan
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Dave DeLong via swift-evolution]

I assume you’re referring to this?
Implicitly treat enums without binary compatibility concerns as @frozen

Several people questioned whether it was necessary to make this distinction for 
libraries without binary compatibility concerns, i.e. those that are shipped 
with their client apps. While there may be a need to do something to handle 
enums shipped with Apple's OS SDKs, it's arguable whether this is worth it for 
"source libraries", such as SwiftPM packages.

This question can be rephrased as "is adding a case to an enum a 
source-breaking change?" 


I don’t follow on how this is a source-breaking change.

Let’s say I’m writing an app “A” that embeds a module “M”, which defines and 
enum “E”.

If E is frozen, the everything’s fine and all is well.
If E is *not* frozen, then the compiler is going to force me to put in an 
“unknown case”, because it has falsely concluded that E may change out from 
underneath my app.

The will be a mistake on the compiler’s part. I do not need to include the 
“unknown case” handler while enumerating on E, because there is no possibility 
of ever getting an unknown enum value from M, because it is statically copied 
in to my app and will never change.

Dave

> On Jan 12, 2018, at 4:16 PM, Jordan Rose  wrote:
> 
> I included that, but also I again don't think that's the correct design. 
> There's a case where that's useful, but that shouldn't be the default, and I 
> don't think it's important enough to do in Swift 5.
> 
> Jordan
> 
> 
>> On Jan 12, 2018, at 15:15, Dave DeLong > > wrote:
>> 
>> Unless I’m missing something, this is still missing the discussion on being 
>> able to treat all enums of internally-packaged libraries as frozen.
>> 
>> IE, that frozen vs unfrozen is only an issue for enums that come from 
>> modules that are not packaged with your app.
>> 
>> Dave
>> 
>>> On Jan 12, 2018, at 4:08 PM, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
>>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
>>> point very specifically: if the compiler emits an error, we should go with 
>>> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
>>> 
>>> I think the revised proposal is in good shape! 
>>> (https://github.com/apple/swift-evolution/pull/777 
>>> ) I think I've addressed 
>>> everyone's feedback either in the proposal or on-list, if not necessarily 
>>> convinced them. If there are no other major comments I'll let Ted know that 
>>> it's ready to re-run on Monday.
>>> 
>>> Jordan
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

I included that, but also I again don't think that's the correct design. 
There's a case where that's useful, but that shouldn't be the default, and I 
don't think it's important enough to do in Swift 5.

Jordan


> On Jan 12, 2018, at 15:15, Dave DeLong  wrote:
> 
> Unless I’m missing something, this is still missing the discussion on being 
> able to treat all enums of internally-packaged libraries as frozen.
> 
> IE, that frozen vs unfrozen is only an issue for enums that come from modules 
> that are not packaged with your app.
> 
> Dave
> 
>> On Jan 12, 2018, at 4:08 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
>> point very specifically: if the compiler emits an error, we should go with 
>> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
>> 
>> I think the revised proposal is in good shape! 
>> (https://github.com/apple/swift-evolution/pull/777) I think I've addressed 
>> everyone's feedback either in the proposal or on-list, if not necessarily 
>> convinced them. If there are no other major comments I'll let Ted know that 
>> it's ready to re-run on Monday.
>> 
>> Jordan
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Dave DeLong via swift-evolution]

Unless I’m missing something, this is still missing the discussion on being 
able to treat all enums of internally-packaged libraries as frozen.

IE, that frozen vs unfrozen is only an issue for enums that come from modules 
that are not packaged with your app.

Dave

> On Jan 12, 2018, at 4:08 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
> point very specifically: if the compiler emits an error, we should go with 
> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
> 
> I think the revised proposal is in good shape! 
> (https://github.com/apple/swift-evolution/pull/777) I think I've addressed 
> everyone's feedback either in the proposal or on-list, if not necessarily 
> convinced them. If there are no other major comments I'll let Ted know that 
> it's ready to re-run on Monday.
> 
> Jordan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

Okay, I went back to `unknown case` in the proposal, but mentioned Chris's 
point very specifically: if the compiler emits an error, we should go with 
`case #unknown` instead. (I'm very strongly in the "warning" camp, though.)

I think the revised proposal is in good shape! 
(https://github.com/apple/swift-evolution/pull/777) I think I've addressed 
everyone's feedback either in the proposal or on-list, if not necessarily 
convinced them. If there are no other major comments I'll let Ted know that 
it's ready to re-run on Monday.

Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 12 Jan 2018, at 18:25, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 11, 2018, at 23:30, Chris Lattner  wrote:
>> 
>> 
>>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution 
>>>  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.
> 
> It will not work in catch clauses because you need to have a static type 
> that's an enum. Catch clauses always (today…) have a static type of 'Error'.
> 
> 
>> 
>> 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.
> 
> That's fair. I'm strongly in favor of a warning, though, because again, 
> people don't edit their dependencies.

A warning is better than nothing :), but for third party libraries you include 
in the app you are responsible for not updating to a library that would break 
your build and between compiler and automation catch this error before merging 
a PR and putting it in production. It is also your responsibility to reasonable 
choose a library that is properly maintained and vetted.

> 
> Jordan
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution 
>  wrote:
> 
>> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution 
>> > 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 
 > 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

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jan 12, 2018, at 12:25 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 11, 2018, at 23:30, Chris Lattner  wrote:
>> 
>> 
>>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution 
>>>  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.
> 
> It will not work in catch clauses because you need to have a static type 
> that's an enum. Catch clauses always (today…) have a static type of 'Error'.

Right, although it should work for enum Error types in catch clauses if we add 
typed errors in the future.  That’s worth considering when making this decision.

> 
> 
>> 
>> 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.
> 
> That's fair. I'm strongly in favor of a warning, though, because again, 
> people don't edit their dependencies.
> 
> Jordan
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 11, 2018, at 23:30, Chris Lattner  wrote:
> 
> 
>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution 
>>  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.

It will not work in catch clauses because you need to have a static type that's 
an enum. Catch clauses always (today…) have a static type of 'Error'.


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

That's fair. I'm strongly in favor of a warning, though, because again, people 
don't edit their dependencies.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Michel Fortin via swift-evolution]

> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution 
>  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 
>>>  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

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Vladimir.S via swift-evolution]

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 
 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? Then still the first 'switch' on 
frozen enum confuses the reader.


I understand that we are not discussing the 'private' cases yet, but IMO we should consider how new 'case 
#unknown/unknown default' will be used in case we'll add that feature.


Vladimir.



-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution 
>  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.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jean-Daniel via swift-evolution]

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 ?



> Le 12 janv. 2018 à 02:48, Howard Lovatt via swift-evolution 
>  a écrit :
> 
> Well if you are happy to say removal of a case isn’t allowed, why not be 
> symmetrical and say adding isn’t allowed and if an API would like to add 
> cases then it needs to do so via adding an extended enum, e.g.:
> 
> enum Old {
> case old1, old2
> }
> enum New {
> case old1 // Note missing old2. 
> case new1
> }
> struct Ex {
> func f(old: Old) -> Old { ... }
> func f(new: New) -> New { ... }
> }
> 
> If this approach is taken then it is more work for Apple and less work for 
> developers and a cleaner Swift. So overall it might be the best approach. 
> 
> -- Howard.
> 
> On 11 Jan 2018, at 11:23 am, Jordan Rose via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On Jan 11, 2018, at 05:08, Michel Fortin >> > wrote:
>>> 
>>> I think `unknown` should be a modifier for either `case` or `default`. This 
>>> would allow:
>>> 
>>> unknown default:
>>> unknown case _: // similar to default
>>> unknown case (1, _): // enum in second position
>>> 
>>> If the case can be reached with statically known enum values, the compiler 
>>> generates a warning.
>>> 
>>> I'd also prefer a more precise term instead of "unknown". What we aim at is 
>>> matching cases that do not have a declaration (future cases, 
>>> privately-declared cases). So I'd use the word "undeclared" rather than 
>>> "unknown":
>>> 
>>> undeclared default:
>>> undeclared case _: // similar to default
>>> undeclared case (1, _): // enum in second position
>>> 
>>> That word has the advantage that enums are also less likely to have a case 
>>> named "undeclared", I think.
>> 
>> I’m not sure I’d agree that most people would think of private cases are 
>> “undeclared”, but sure, it’s a reasonable alternative. I still like 
>> “unknown” a little better myself.
>> 
>> Jordan
>> 
>> 
>>> 
 Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution 
 > a écrit :
 
 
> On Jan 10, 2018, at 10:10 AM, Jordan Rose  > wrote:
> 
>>> 
>>> - Matching known cases is a feature, not a limitation, to avoid 
>>> existing code changing meaning when you recompile. I'll admit that's 
>>> not the strongest motivation, though, since other things can change the 
>>> meaning of existing code when you recompile already.
>> 
>> I’m not sure I understand this. 
>> 
>> The whole motivation for this feature is to notify people if they are 
>> not handling a “newly known” case.  If they don’t care about this, they 
>> can just use default.
> 
> Notify, yes. Error, no. It's a design goal that adding a new case does 
> not break source compatibility in addition to not breaking binary 
> compatibility (because people don't like editing their dependencies) and 
> therefore the behavior has to be defined when they recompile with no 
> changes.
> 
 
 Ok, if that’s the desired design, then (IMO) the right way to spell it is 
 “unknown default:” and it should have semantics basically aligned with the 
 design you laid out in the revision of the proposal.  If this is supposed 
 to be an error, then it should be a pattern production.
 
 Do you have a sense for whether this is what people want?  We really 
 should have a review cycle evaluating exactly this sort of tradeoff.
 
 In any case, I’ve said this before off-list, but I find this whole 
 discussion (of how to improve diagnostics for unknown cases) to be 
 separable from the core issue required to get to ABI stability.  It seems 
 to me that we could split this (ongoing) design discussion off into a 
 separate SE, allowing you to get on with the relatively uncontroversial 
 and critical parts in SE-0192.
 
 -Chris
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> 
>>> 
>>> -- 
>>> Michel Fortin
>>> https://michelf.ca 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> 

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jean-Daniel via swift-evolution]

Going that way, we can also deny addition of new members in a struct.

Moreover, while you think that only Apple is interested in having binary 
stability, this is far to be true, and Apple OSes are not the only OS where 
Swift can be used.

> Le 12 janv. 2018 à 02:48, Howard Lovatt via swift-evolution 
>  a écrit :
> 
> Well if you are happy to say removal of a case isn’t allowed, why not be 
> symmetrical and say adding isn’t allowed and if an API would like to add 
> cases then it needs to do so via adding an extended enum, e.g.:
> 
> enum Old {
> case old1, old2
> }
> enum New {
> case old1 // Note missing old2. 
> case new1
> }
> struct Ex {
> func f(old: Old) -> Old { ... }
> func f(new: New) -> New { ... }
> }
> 
> If this approach is taken then it is more work for Apple and less work for 
> developers and a cleaner Swift. So overall it might be the best approach. 
> 
> -- Howard.
> 
> On 11 Jan 2018, at 11:23 am, Jordan Rose via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On Jan 11, 2018, at 05:08, Michel Fortin >> > wrote:
>>> 
>>> I think `unknown` should be a modifier for either `case` or `default`. This 
>>> would allow:
>>> 
>>> unknown default:
>>> unknown case _: // similar to default
>>> unknown case (1, _): // enum in second position
>>> 
>>> If the case can be reached with statically known enum values, the compiler 
>>> generates a warning.
>>> 
>>> I'd also prefer a more precise term instead of "unknown". What we aim at is 
>>> matching cases that do not have a declaration (future cases, 
>>> privately-declared cases). So I'd use the word "undeclared" rather than 
>>> "unknown":
>>> 
>>> undeclared default:
>>> undeclared case _: // similar to default
>>> undeclared case (1, _): // enum in second position
>>> 
>>> That word has the advantage that enums are also less likely to have a case 
>>> named "undeclared", I think.
>> 
>> I’m not sure I’d agree that most people would think of private cases are 
>> “undeclared”, but sure, it’s a reasonable alternative. I still like 
>> “unknown” a little better myself.
>> 
>> Jordan
>> 
>> 
>>> 
 Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution 
 > a écrit :
 
 
> On Jan 10, 2018, at 10:10 AM, Jordan Rose  > wrote:
> 
>>> 
>>> - Matching known cases is a feature, not a limitation, to avoid 
>>> existing code changing meaning when you recompile. I'll admit that's 
>>> not the strongest motivation, though, since other things can change the 
>>> meaning of existing code when you recompile already.
>> 
>> I’m not sure I understand this. 
>> 
>> The whole motivation for this feature is to notify people if they are 
>> not handling a “newly known” case.  If they don’t care about this, they 
>> can just use default.
> 
> Notify, yes. Error, no. It's a design goal that adding a new case does 
> not break source compatibility in addition to not breaking binary 
> compatibility (because people don't like editing their dependencies) and 
> therefore the behavior has to be defined when they recompile with no 
> changes.
> 
 
 Ok, if that’s the desired design, then (IMO) the right way to spell it is 
 “unknown default:” and it should have semantics basically aligned with the 
 design you laid out in the revision of the proposal.  If this is supposed 
 to be an error, then it should be a pattern production.
 
 Do you have a sense for whether this is what people want?  We really 
 should have a review cycle evaluating exactly this sort of tradeoff.
 
 In any case, I’ve said this before off-list, but I find this whole 
 discussion (of how to improve diagnostics for unknown cases) to be 
 separable from the core issue required to get to ABI stability.  It seems 
 to me that we could split this (ongoing) design discussion off into a 
 separate SE, allowing you to get on with the relatively uncontroversial 
 and critical parts in SE-0192.
 
 -Chris
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> 
>>> 
>>> -- 
>>> Michel Fortin
>>> https://michelf.ca 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Howard Lovatt via swift-evolution]

Well if you are happy to say removal of a case isn’t allowed, why not be 
symmetrical and say adding isn’t allowed and if an API would like to add cases 
then it needs to do so via adding an extended enum, e.g.:

enum Old {
case old1, old2
}
enum New {
case old1 // Note missing old2. 
case new1
}
struct Ex {
func f(old: Old) -> Old { ... }
func f(new: New) -> New { ... }
}

If this approach is taken then it is more work for Apple and less work for 
developers and a cleaner Swift. So overall it might be the best approach. 

-- Howard.

> On 11 Jan 2018, at 11:23 am, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 11, 2018, at 05:08, Michel Fortin  wrote:
>> 
>> I think `unknown` should be a modifier for either `case` or `default`. This 
>> would allow:
>> 
>>  unknown default:
>>  unknown case _: // similar to default
>>  unknown case (1, _): // enum in second position
>> 
>> If the case can be reached with statically known enum values, the compiler 
>> generates a warning.
>> 
>> I'd also prefer a more precise term instead of "unknown". What we aim at is 
>> matching cases that do not have a declaration (future cases, 
>> privately-declared cases). So I'd use the word "undeclared" rather than 
>> "unknown":
>> 
>>  undeclared default:
>>  undeclared case _: // similar to default
>>  undeclared case (1, _): // enum in second position
>> 
>> That word has the advantage that enums are also less likely to have a case 
>> named "undeclared", I think.
> 
> I’m not sure I’d agree that most people would think of private cases are 
> “undeclared”, but sure, it’s a reasonable alternative. I still like “unknown” 
> a little better myself.
> 
> Jordan
> 
> 
>> 
 Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution 
  a écrit :
 
 
 On Jan 10, 2018, at 10:10 AM, Jordan Rose  wrote:
 
>> 
>> - Matching known cases is a feature, not a limitation, to avoid existing 
>> code changing meaning when you recompile. I'll admit that's not the 
>> strongest motivation, though, since other things can change the meaning 
>> of existing code when you recompile already.
> 
> I’m not sure I understand this. 
> 
> The whole motivation for this feature is to notify people if they are not 
> handling a “newly known” case.  If they don’t care about this, they can 
> just use default.
 
 Notify, yes. Error, no. It's a design goal that adding a new case does not 
 break source compatibility in addition to not breaking binary 
 compatibility (because people don't like editing their dependencies) and 
 therefore the behavior has to be defined when they recompile with no 
 changes.
 
>>> 
>>> Ok, if that’s the desired design, then (IMO) the right way to spell it is 
>>> “unknown default:” and it should have semantics basically aligned with the 
>>> design you laid out in the revision of the proposal.  If this is supposed 
>>> to be an error, then it should be a pattern production.
>>> 
>>> Do you have a sense for whether this is what people want?  We really should 
>>> have a review cycle evaluating exactly this sort of tradeoff.
>>> 
>>> In any case, I’ve said this before off-list, but I find this whole 
>>> discussion (of how to improve diagnostics for unknown cases) to be 
>>> separable from the core issue required to get to ABI stability.  It seems 
>>> to me that we could split this (ongoing) design discussion off into a 
>>> separate SE, allowing you to get on with the relatively uncontroversial and 
>>> critical parts in SE-0192.
>>> 
>>> -Chris
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> -- 
>> Michel Fortin
>> https://michelf.ca
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 11, 2018, at 05:08, Michel Fortin  wrote:
> 
> I think `unknown` should be a modifier for either `case` or `default`. This 
> would allow:
> 
>   unknown default:
>   unknown case _: // similar to default
>   unknown case (1, _): // enum in second position
> 
> If the case can be reached with statically known enum values, the compiler 
> generates a warning.
> 
> I'd also prefer a more precise term instead of "unknown". What we aim at is 
> matching cases that do not have a declaration (future cases, 
> privately-declared cases). So I'd use the word "undeclared" rather than 
> "unknown":
> 
>   undeclared default:
>   undeclared case _: // similar to default
>   undeclared case (1, _): // enum in second position
> 
> That word has the advantage that enums are also less likely to have a case 
> named "undeclared", I think.

I’m not sure I’d agree that most people would think of private cases are 
“undeclared”, but sure, it’s a reasonable alternative. I still like “unknown” a 
little better myself.

Jordan


> 
>> Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution 
>> > a écrit :
>> 
>> 
>>> On Jan 10, 2018, at 10:10 AM, Jordan Rose >> > wrote:
>>> 
> 
> - Matching known cases is a feature, not a limitation, to avoid existing 
> code changing meaning when you recompile. I'll admit that's not the 
> strongest motivation, though, since other things can change the meaning 
> of existing code when you recompile already.
 
 I’m not sure I understand this. 
 
 The whole motivation for this feature is to notify people if they are not 
 handling a “newly known” case.  If they don’t care about this, they can 
 just use default.
>>> 
>>> Notify, yes. Error, no. It's a design goal that adding a new case does not 
>>> break source compatibility in addition to not breaking binary compatibility 
>>> (because people don't like editing their dependencies) and therefore the 
>>> behavior has to be defined when they recompile with no changes.
>>> 
>> 
>> Ok, if that’s the desired design, then (IMO) the right way to spell it is 
>> “unknown default:” and it should have semantics basically aligned with the 
>> design you laid out in the revision of the proposal.  If this is supposed to 
>> be an error, then it should be a pattern production.
>> 
>> Do you have a sense for whether this is what people want?  We really should 
>> have a review cycle evaluating exactly this sort of tradeoff.
>> 
>> In any case, I’ve said this before off-list, but I find this whole 
>> discussion (of how to improve diagnostics for unknown cases) to be separable 
>> from the core issue required to get to ABI stability.  It seems to me that 
>> we could split this (ongoing) design discussion off into a separate SE, 
>> allowing you to get on with the relatively uncontroversial and critical 
>> parts in SE-0192.
>> 
>> -Chris
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> -- 
> Michel Fortin
> https://michelf.ca 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

Removing cases just isn’t allowed. They can be deprecated, but actually 
removing one is a breaking change. With a Swift enum the app will actually fail 
to launch with a dynamic linking error.

Jordan


> On Jan 10, 2018, at 21:27, Howard Lovatt  wrote:
> 
> It is a two way street though. An app compiled against an old framework might 
> pass a deleted enum case back to the new framework that has been changed 
> under it. 
> 
> Just as the app has to guard against new cases the framework has to guard 
> against old cases!
> 
> Both ends need an unknown case. 
> 
> -- Howard. 
> 
>> On 10 Jan 2018, at 5:40 pm, Jordan Rose  wrote:
>> 
>> Remember, the goal here is to support both binary and source compatibility. 
>> An existing app might be using the enum case that you're trying to remove, 
>> but there's no chance that an existing app is using an enum case that you're 
>> trying to add.
>> 
>> Jordan
>> 
>> 
>>> On Jan 10, 2018, at 16:34, Howard Lovatt via swift-evolution 
>>>  wrote:
>>> 
>>> If an enum isn’t final; then what’s the difference in deleting as opposed 
>>> to adding?
>>> 
>>> -- Howard. 
>>> 
 On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
 
 
 
> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>  a écrit :
> 
> Two points:
> 
> 1. I like Chris’s suggestion of #unknown and in particular that it is 
> distinct from default. 
> 
> 2. All the discussion is about a framework adding a case, what about when 
> a framework deletes a case?
 
 This is a binary breaking change (just like removing an existing function 
 or method).
 
 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Michel Fortin via swift-evolution]

I think `unknown` should be a modifier for either `case` or `default`. This 
would allow:

unknown default:
unknown case _: // similar to default
unknown case (1, _): // enum in second position

If the case can be reached with statically known enum values, the compiler 
generates a warning.

I'd also prefer a more precise term instead of "unknown". What we aim at is 
matching cases that do not have a declaration (future cases, privately-declared 
cases). So I'd use the word "undeclared" rather than "unknown":

undeclared default:
undeclared case _: // similar to default
undeclared case (1, _): // enum in second position

That word has the advantage that enums are also less likely to have a case 
named "undeclared", I think.

> Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution 
>  a écrit :
> 
> 
>> On Jan 10, 2018, at 10:10 AM, Jordan Rose > > wrote:
>> 
 
 - Matching known cases is a feature, not a limitation, to avoid existing 
 code changing meaning when you recompile. I'll admit that's not the 
 strongest motivation, though, since other things can change the meaning of 
 existing code when you recompile already.
>>> 
>>> I’m not sure I understand this. 
>>> 
>>> The whole motivation for this feature is to notify people if they are not 
>>> handling a “newly known” case.  If they don’t care about this, they can 
>>> just use default.
>> 
>> Notify, yes. Error, no. It's a design goal that adding a new case does not 
>> break source compatibility in addition to not breaking binary compatibility 
>> (because people don't like editing their dependencies) and therefore the 
>> behavior has to be defined when they recompile with no changes.
>> 
> 
> Ok, if that’s the desired design, then (IMO) the right way to spell it is 
> “unknown default:” and it should have semantics basically aligned with the 
> design you laid out in the revision of the proposal.  If this is supposed to 
> be an error, then it should be a pattern production.
> 
> Do you have a sense for whether this is what people want?  We really should 
> have a review cycle evaluating exactly this sort of tradeoff.
> 
> In any case, I’ve said this before off-list, but I find this whole discussion 
> (of how to improve diagnostics for unknown cases) to be separable from the 
> core issue required to get to ABI stability.  It seems to me that we could 
> split this (ongoing) design discussion off into a separate SE, allowing you 
> to get on with the relatively uncontroversial and critical parts in SE-0192.
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



-- 
Michel Fortin
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jean-Daniel via swift-evolution]

Let say you have a module that declare a enum and also declare a function that 
take that enum as parameter and switch over it.

As there is no cross module boundary, the switch don’t require #unknown or any 
fancy trick to be exhaustive.

Now if you remove the case from the enum, any client code that call your 
function by passing the enum will cause a crash.

The following is just blind guess as I don’t have any knowledge of the swift 
compiler, but as Swift cases are not necessarily simple Int, maybe there some 
times swift has to generates symbols for complex cases.
In such case, removing an enum will be even more harmful as it will cause a 
crash a start for missing symbol (assuming at such time Apple did switch to 
dyld3 which bound at launch and not lazily).


> Le 11 janv. 2018 à 01:34, Howard Lovatt  a écrit :
> 
> If an enum isn’t final; then what’s the difference in deleting as opposed to 
> adding?
> 
> -- Howard. 
> 
>> On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
>> 
>> 
>> 
>>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>>>  a écrit :
>>> 
>>> Two points:
>>> 
>>> 1. I like Chris’s suggestion of #unknown and in particular that it is 
>>> distinct from default. 
>>> 
>>> 2. All the discussion is about a framework adding a case, what about when a 
>>> framework deletes a case?
>> 
>> This is a binary breaking change (just like removing an existing function or 
>> method).
>> 
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Howard Lovatt via swift-evolution]

It is a two way street though. An app compiled against an old framework might 
pass a deleted enum case back to the new framework that has been changed under 
it. 

Just as the app has to guard against new cases the framework has to guard 
against old cases!

Both ends need an unknown case. 

-- Howard. 

> On 10 Jan 2018, at 5:40 pm, Jordan Rose  wrote:
> 
> Remember, the goal here is to support both binary and source compatibility. 
> An existing app might be using the enum case that you're trying to remove, 
> but there's no chance that an existing app is using an enum case that you're 
> trying to add.
> 
> Jordan
> 
> 
>> On Jan 10, 2018, at 16:34, Howard Lovatt via swift-evolution 
>>  wrote:
>> 
>> If an enum isn’t final; then what’s the difference in deleting as opposed to 
>> adding?
>> 
>> -- Howard. 
>> 
>>> On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
>>> 
>>> 
>>> 
 Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
  a écrit :
 
 Two points:
 
 1. I like Chris’s suggestion of #unknown and in particular that it is 
 distinct from default. 
 
 2. All the discussion is about a framework adding a case, what about when 
 a framework deletes a case?
>>> 
>>> This is a binary breaking change (just like removing an existing function 
>>> or method).
>>> 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Goffredo Marocchi via swift-evolution]

I am sorry, but I have to disagree here. Having two separate proposals would 
make it highly more likely that one thing is done and the other one postponed 
and postponed until it seems no longer relevant in the grand scheme of 
things... first we lost labels in callbacks / stores functions (has there been 
at least some Core Team chat about this after last year?) and now we are losing 
compiler enforced exhaustive switching over enum... not only that, until we 
improve diagnostic and at least warn users we are now even behind Objective-C 
as compiler can enforce exhaustive switching and actually mandate no default 
case for enums through a compiler warning.

Sent from my iPhone

> On 11 Jan 2018, at 04:31, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jan 10, 2018, at 10:10 AM, Jordan Rose  wrote:
>> 
 
 - Matching known cases is a feature, not a limitation, to avoid existing 
 code changing meaning when you recompile. I'll admit that's not the 
 strongest motivation, though, since other things can change the meaning of 
 existing code when you recompile already.
>>> 
>>> I’m not sure I understand this. 
>>> 
>>> The whole motivation for this feature is to notify people if they are not 
>>> handling a “newly known” case.  If they don’t care about this, they can 
>>> just use default.
>> 
>> Notify, yes. Error, no. It's a design goal that adding a new case does not 
>> break source compatibility in addition to not breaking binary compatibility 
>> (because people don't like editing their dependencies) and therefore the 
>> behavior has to be defined when they recompile with no changes.
>> 
> 
> Ok, if that’s the desired design, then (IMO) the right way to spell it is 
> “unknown default:” and it should have semantics basically aligned with the 
> design you laid out in the revision of the proposal.  If this is supposed to 
> be an error, then it should be a pattern production.
> 
> Do you have a sense for whether this is what people want?  We really should 
> have a review cycle evaluating exactly this sort of tradeoff.
> 
> In any case, I’ve said this before off-list, but I find this whole discussion 
> (of how to improve diagnostics for unknown cases) to be separable from the 
> core issue required to get to ABI stability.  It seems to me that we could 
> split this (ongoing) design discussion off into a separate SE, allowing you 
> to get on with the relatively uncontroversial and critical parts in SE-0192.
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

> On Jan 10, 2018, at 10:10 AM, Jordan Rose  wrote:
> 
>>> 
>>> - Matching known cases is a feature, not a limitation, to avoid existing 
>>> code changing meaning when you recompile. I'll admit that's not the 
>>> strongest motivation, though, since other things can change the meaning of 
>>> existing code when you recompile already.
>> 
>> I’m not sure I understand this. 
>> 
>> The whole motivation for this feature is to notify people if they are not 
>> handling a “newly known” case.  If they don’t care about this, they can just 
>> use default.
> 
> Notify, yes. Error, no. It's a design goal that adding a new case does not 
> break source compatibility in addition to not breaking binary compatibility 
> (because people don't like editing their dependencies) and therefore the 
> behavior has to be defined when they recompile with no changes.
> 

Ok, if that’s the desired design, then (IMO) the right way to spell it is 
“unknown default:” and it should have semantics basically aligned with the 
design you laid out in the revision of the proposal.  If this is supposed to be 
an error, then it should be a pattern production.

Do you have a sense for whether this is what people want?  We really should 
have a review cycle evaluating exactly this sort of tradeoff.

In any case, I’ve said this before off-list, but I find this whole discussion 
(of how to improve diagnostics for unknown cases) to be separable from the core 
issue required to get to ABI stability.  It seems to me that we could split 
this (ongoing) design discussion off into a separate SE, allowing you to get on 
with the relatively uncontroversial and critical parts in SE-0192.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

Remember, the goal here is to support both binary and source compatibility. An 
existing app might be using the enum case that you're trying to remove, but 
there's no chance that an existing app is using an enum case that you're trying 
to add.

Jordan


> On Jan 10, 2018, at 16:34, Howard Lovatt via swift-evolution 
>  wrote:
> 
> If an enum isn’t final; then what’s the difference in deleting as opposed to 
> adding?
> 
> -- Howard. 
> 
>> On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
>> 
>> 
>> 
>>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>>>  a écrit :
>>> 
>>> Two points:
>>> 
>>> 1. I like Chris’s suggestion of #unknown and in particular that it is 
>>> distinct from default. 
>>> 
>>> 2. All the discussion is about a framework adding a case, what about when a 
>>> framework deletes a case?
>> 
>> This is a binary breaking change (just like removing an existing function or 
>> method).
>> 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Howard Lovatt via swift-evolution]

If an enum isn’t final; then what’s the difference in deleting as opposed to 
adding?

-- Howard. 

> On 10 Jan 2018, at 4:13 pm, Jean-Daniel  wrote:
> 
> 
> 
>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>>  a écrit :
>> 
>> Two points:
>> 
>> 1. I like Chris’s suggestion of #unknown and in particular that it is 
>> distinct from default. 
>> 
>> 2. All the discussion is about a framework adding a case, what about when a 
>> framework deletes a case?
> 
> This is a binary breaking change (just like removing an existing function or 
> method).
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Mike Kluev via swift-evolution]

on Wed, 10 Jan 2018 07:12:27 + Antoine Cœur 
wrote:

>
> And what about, as an alternative:
>
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case _:  … matches anything ...
>
> Then it clearly goes the "pattern matching" way.
>

this will be logical and consistent. or #default everywhere instead of _

case (#default, #unknown):
case #default:

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jean-Daniel via swift-evolution]

> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution 
>  a écrit :
> 
> Two points:
> 
> 1. I like Chris’s suggestion of #unknown and in particular that it is 
> distinct from default. 
> 
> 2. All the discussion is about a framework adding a case, what about when a 
> framework deletes a case?

This is a binary breaking change (just like removing an existing function or 
method).


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Howard Lovatt via swift-evolution]

Two points:

1. I like Chris’s suggestion of #unknown and in particular that it is distinct 
from default. 

2. All the discussion is about a framework adding a case, what about when a 
framework deletes a case?

-- Howard.

> On 10 Jan 2018, at 1:41 pm, Dave DeLong via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 10, 2018, at 1:29 PM, Dave DeLong via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
> That said, it sounds like people are happier with `case #unknown` than 
> `unknown case`, and that leaves things a little more consistent if we 
> ever do expand it to other pattern positions, so I'll change the proposal 
> revision to use that spelling. (And if anyone comes up with a nicer 
> spelling, great!)
 
 Thanks!
>>> 
>>> Updated! https://github.com/apple/swift-evolution/pull/777. Also tried to 
>>> clarify some of the points on why I'm leery about #unknown as an arbitrary 
>>> pattern, at least for now.
>> 
>> Hi Jordan,
>> 
>> After a long and hard reading, I will conditionally +1 this:
>> 
>> I agree that this is a problem that “needs" to be solved. (“Needs” is 
>> subjective, because as you correctly point out, there are other languages 
>> that don’t do this and seem to be relatively OK with that)
>> I am ok with the @frozen moniker on enums
>> I am ok with the “#unknown” syntax
>> I am therefore generally ok with the proposed solution
>> 
>> BUT:
>> 
>> I think the application of the warnings is still overly broad. The 
>> frozenness of an enum is only a problem for enums that come from dynamically 
>> linked modules that are external to my built project.
>> 
>> Therefore I’d like to see stuff regarding:
>> 
>> future directions for how we can refine the behavior and tooling around 
>> frozen enums, specifically
>> “statically” linking libraries (ie, the “import Module1 @ 12.1.2” stuff, aka 
>> “version locking"), because statically linking should eliminate frozenness 
>> concerns
>> embedded modules not producing warnings in the future, because embedded 
>> modules only change when the app author decides
>> ruminations on improving tooling for yelling at a developer if they 
>> “unfreeze” an enum in between versions (ie, a reduction of the SemVer 
>> conversation)
>> 
>> Because version locking and knowledge of embedding modules doesn’t currently 
>> exist, we’re forced to deal with the over-applicability of frozenness that 
>> shouldn’t be necessary. Getting those in would go a long way towards getting 
>> this feature scoped down to where it properly belongs in the app development 
>> workflow.
> 
> In other words, the current solution will produce a bunch of false positives, 
> and I’d like to see stuff in the proposal about how those false positives 
> will be addressed.
> 
> Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Dave DeLong via swift-evolution]

> On Jan 10, 2018, at 1:29 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> 
 That said, it sounds like people are happier with `case #unknown` than 
 `unknown case`, and that leaves things a little more consistent if we ever 
 do expand it to other pattern positions, so I'll change the proposal 
 revision to use that spelling. (And if anyone comes up with a nicer 
 spelling, great!)
>>> 
>>> Thanks!
>> 
>> Updated! https://github.com/apple/swift-evolution/pull/777 
>> . Also tried to clarify 
>> some of the points on why I'm leery about #unknown as an arbitrary pattern, 
>> at least for now.
> 
> Hi Jordan,
> 
> After a long and hard reading, I will conditionally +1 this:
> 
> I agree that this is a problem that “needs" to be solved. (“Needs” is 
> subjective, because as you correctly point out, there are other languages 
> that don’t do this and seem to be relatively OK with that)
> I am ok with the @frozen moniker on enums
> I am ok with the “#unknown” syntax
> I am therefore generally ok with the proposed solution
> 
> BUT:
> 
> I think the application of the warnings is still overly broad. The frozenness 
> of an enum is only a problem for enums that come from dynamically linked 
> modules that are external to my built project.
> 
> Therefore I’d like to see stuff regarding:
> 
> future directions for how we can refine the behavior and tooling around 
> frozen enums, specifically
> “statically” linking libraries (ie, the “import Module1 @ 12.1.2” stuff, aka 
> “version locking"), because statically linking should eliminate frozenness 
> concerns
> embedded modules not producing warnings in the future, because embedded 
> modules only change when the app author decides
> ruminations on improving tooling for yelling at a developer if they 
> “unfreeze” an enum in between versions (ie, a reduction of the SemVer 
> conversation)
> 
> Because version locking and knowledge of embedding modules doesn’t currently 
> exist, we’re forced to deal with the over-applicability of frozenness that 
> shouldn’t be necessary. Getting those in would go a long way towards getting 
> this feature scoped down to where it properly belongs in the app development 
> workflow.

In other words, the current solution will produce a bunch of false positives, 
and I’d like to see stuff in the proposal about how those false positives will 
be addressed.

Dave___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Dave DeLong via swift-evolution]

> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>>> That said, it sounds like people are happier with `case #unknown` than 
>>> `unknown case`, and that leaves things a little more consistent if we ever 
>>> do expand it to other pattern positions, so I'll change the proposal 
>>> revision to use that spelling. (And if anyone comes up with a nicer 
>>> spelling, great!)
>> 
>> Thanks!
> 
> Updated! https://github.com/apple/swift-evolution/pull/777 
> . Also tried to clarify 
> some of the points on why I'm leery about #unknown as an arbitrary pattern, 
> at least for now.

Hi Jordan,

After a long and hard reading, I will conditionally +1 this:

I agree that this is a problem that “needs" to be solved. (“Needs” is 
subjective, because as you correctly point out, there are other languages that 
don’t do this and seem to be relatively OK with that)
I am ok with the @frozen moniker on enums
I am ok with the “#unknown” syntax
I am therefore generally ok with the proposed solution

BUT:

I think the application of the warnings is still overly broad. The frozenness 
of an enum is only a problem for enums that come from dynamically linked 
modules that are external to my built project.

Therefore I’d like to see stuff regarding:

future directions for how we can refine the behavior and tooling around frozen 
enums, specifically
“statically” linking libraries (ie, the “import Module1 @ 12.1.2” stuff, aka 
“version locking"), because statically linking should eliminate frozenness 
concerns
embedded modules not producing warnings in the future, because embedded modules 
only change when the app author decides
ruminations on improving tooling for yelling at a developer if they “unfreeze” 
an enum in between versions (ie, a reduction of the SemVer conversation)

Because version locking and knowledge of embedding modules doesn’t currently 
exist, we’re forced to deal with the over-applicability of frozenness that 
shouldn’t be necessary. Getting those in would go a long way towards getting 
this feature scoped down to where it properly belongs in the app development 
workflow.

Dave___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 10, 2018, at 12:04, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 
> 
> On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner  > wrote:
> On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez  > wrote:
> > Hi Chris,
> >
> > This is great. Thanks for spending time on this! I am in favor of `case 
> > #unknown` to only match unknown cases.
> >
> > 1) Would #uknown be available to RawRepresentable structs?
> 
> I haven’t considered this, so I’m not sure how that would work.  I had 
> assumed that this would be an enum specific concept.
> 
> What do you have in mind?  If your raw representation is itself an enum, then 
> of course this would work.
> 
> I was just curious since a RawRepresentable structs ( and OptionSet ) are 
> very similar to non exhaustive enums in that they would require handling 
> unknown cases. Currently RawRepresentable is required to use a default even 
> if all cases are accounted for. 
> 
> struct Directions: OptionSet {
> let rawValue: UInt8
> static let up= Directions(rawValue: 1 << 0)
> }
> 
> let myDir = Directions.up
> 
> switch myDir
> {
> case .up : print("matched")
> default: print("default required") 
> }

Since an option set has 2^N possible values, not just N, we don't expect anyone 
to be switching over them! And it wouldn't be correct to try to do so 
exhaustively anyway.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

>> That said, it sounds like people are happier with `case #unknown` than 
>> `unknown case`, and that leaves things a little more consistent if we ever 
>> do expand it to other pattern positions, so I'll change the proposal 
>> revision to use that spelling. (And if anyone comes up with a nicer 
>> spelling, great!)
> 
> Thanks!

Updated! https://github.com/apple/swift-evolution/pull/777. Also tried to 
clarify some of the points on why I'm leery about #unknown as an arbitrary 
pattern, at least for now.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jose Cheyo Jimenez via swift-evolution]

On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner  wrote:

> On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez 
> wrote:
> > Hi Chris,
> >
> > This is great. Thanks for spending time on this! I am in favor of `case
> #unknown` to only match unknown cases.
> >
> > 1) Would #uknown be available to RawRepresentable structs?
>
> I haven’t considered this, so I’m not sure how that would work.  I had
> assumed that this would be an enum specific concept.
>
> What do you have in mind?  If your raw representation is itself an enum,
> then of course this would work.
>

I was just curious since a RawRepresentable structs ( and OptionSet ) are
very similar to non exhaustive enums in that they would require handling
unknown cases. Currently RawRepresentable is required to use a default even
if all cases are accounted for.

struct Directions: OptionSet {
let rawValue: UInt8
static let up= Directions(rawValue: 1 << 0)
}

let myDir = Directions.up

switch myDir
{
case .up : print("matched")
default: print("default required")
}



> > 2) How is the #uknown pattern accomplished? Are you suggesting to
> capture all the compile time known cases so you can do a diff during
> > runtime? (Sorry this is not obvious to me)
>
> The internals of the compiler would handle this, it is difficult to
> explain unless you know the bowels of silgen and irgen :-)
>
> -Chris
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 9, 2018, at 22:17, Chris Lattner  wrote:
> 
> On Jan 9, 2018, at 4:46 PM, Jordan Rose  > wrote:
>> Thanks for writing this up, Chris! I addressed the idea of making this an 
>> arbitrary pattern in the revised proposal 
>> ,
>>  and the idea of not matching known cases in a "considered alternative" 
>> ,
>>  but in short:
>> 
>> - Matching in arbitrary pattern positions is harder to implement and harder 
>> to produce good diagnostics for. (Specifically, the former comes from having 
>> to actually check the existing cases in the generated code rather than just 
>> having an "else" branch.) I'm not inherently opposed to it if we can all 
>> agree on what it means, but I don't think I have time to implement it for 
>> Swift 5, so I'm not including it in the proposal.
> 
> I’m not sure what you’re saying here.  This does slot directly into the 
> existing pattern design: it is just a new terminal pattern node.  Are you 
> saying the SILGen/IRGen is more difficult and therefore you’re not interested 
> in doing it even if it is the better design?  
> 
> If that is the case, then the conservatively correct thing to do (in my 
> opinion) is to add no feature here: no “unknown case:” and no “case 
> #unknown:’.
> 
> Alternatively are you saying that you intend to support only the “case 
> #unknown:” form exactly, but not the recursive cases?
> 
>> - Matching known cases is a feature, not a limitation, to avoid existing 
>> code changing meaning when you recompile. I'll admit that's not the 
>> strongest motivation, though, since other things can change the meaning of 
>> existing code when you recompile already.
> 
> I’m not sure I understand this. 
> 
> The whole motivation for this feature is to notify people if they are not 
> handling a “newly known” case.  If they don’t care about this, they can just 
> use default.

Notify, yes. Error, no. It's a design goal that adding a new case does not 
break source compatibility in addition to not breaking binary compatibility 
(because people don't like editing their dependencies) and therefore the 
behavior has to be defined when they recompile with no changes.

(This should also cover why it's more difficult to implement both diagnostics 
and SILGen for it.)

Jordan


> 
>> - FWIW I can't actually think of a use case for using this with `if case` or 
>> anything else. I'm not against it, but I don't know why you would ever do 
>> it, just like I don't know why you would mix `case #unknown` with `default` 
>> when matching against a single value.
> 
> Brent gave a simple example down thread.  That said, I’m more concerned about 
> keeping pattern matching simple and composable than I am about particular use 
> cases (I agree the top level case in a switch on enum is the 
> disproportionately important case). 
> 
> At some point we will hopefully extend pattern matching to support regexes 
> and other things, we want to keep the design consistent.
> 
>> That said, it sounds like people are happier with `case #unknown` than 
>> `unknown case`, and that leaves things a little more consistent if we ever 
>> do expand it to other pattern positions, so I'll change the proposal 
>> revision to use that spelling. (And if anyone comes up with a nicer 
>> spelling, great!)
> 
> Thanks!
> 
> -Chris
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 9, 2018, at 21:39, Brent Royal-Gordon  wrote:
> 
> 
> 
>> On Jan 9, 2018, at 4:46 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> - FWIW I can't actually think of a use case for using this with `if case` or 
>> anything else. I'm not against it, but I don't know why you would ever do 
>> it, just like I don't know why you would mix `case #unknown` with `default` 
>> when matching against a single value.
> 
>   if case #unknown = someEnum {
>   throw MyError.unknownValue
>   }
>   …

Yes, you can write that, but why would you do it? What are you going to do 
below now that you know 'someEnum' is a known value but the compiler doesn't?

(Also, it doesn't play well with recompiling…)


> 
>> That said, it sounds like people are happier with `case #unknown` than 
>> `unknown case`, and that leaves things a little more consistent if we ever 
>> do expand it to other pattern positions, so I'll change the proposal 
>> revision to use that spelling. (And if anyone comes up with a nicer 
>> spelling, great!)
> 
> I don't love the spelling of `#unknown`—particularly since some enums in the 
> Apple frameworks actually *have* an ordinary case called "unknown"—but I 
> think it's a nice, pragmatic solution which slots into pattern matching very 
> nicely.
> 
> (And if we ever *do* decide to support @testable enum parameters, we'll 
> already have the syntax to specify unknown values.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Antoine Cœur via swift-evolution]

And what about, as an alternative:

case (_, #unknown): …  matches any int and any unknown enum case ...
case _:  … matches anything ...

Then it clearly goes the "pattern matching" way.


Le mer. 10 janv. 2018 à 14:17, Chris Lattner via swift-evolution <
swift-evolution@swift.org> a écrit :

> On Jan 9, 2018, at 4:46 PM, Jordan Rose  wrote:
>
> Thanks for writing this up, Chris! I addressed the idea of making this an
> arbitrary pattern in the revised proposal
> ,
> and the idea of not matching known cases in a "considered alternative"
> ,
> but in short:
>
> - Matching in arbitrary pattern positions is harder to implement and
> harder to produce good diagnostics for. (Specifically, the former comes
> from having to actually check the existing cases in the generated code
> rather than just having an "else" branch.) I'm not inherently opposed to it
> if we can all agree on what it means, but I don't think I have time to
> implement it for Swift 5, so I'm not including it in the proposal.
>
>
> I’m not sure what you’re saying here.  This does slot directly into the
> existing pattern design: it is just a new terminal pattern node.  Are you
> saying the SILGen/IRGen is more difficult and therefore you’re not
> interested in doing it even if it is the better design?
>
> If that is the case, then the conservatively correct thing to do (in my
> opinion) is to add no feature here: no “unknown case:” and no “case
> #unknown:’.
>
> Alternatively are you saying that you intend to support only the “case
> #unknown:” form exactly, but not the recursive cases?
>
> - Matching known cases is a feature, not a limitation, to avoid existing
> code changing meaning when you recompile. I'll admit that's not the
> strongest motivation, though, since other things can change the meaning of
> existing code when you recompile already.
>
>
> I’m not sure I understand this.
>
> The whole motivation for this feature is to notify people if they are not
> handling a “newly known” case.  If they don’t care about this, they can
> just use default.
>
> - FWIW I can't actually think of a use case for using this with `if case`
> or anything else. I'm not against it, but I don't know why you would ever
> do it, just like I don't know why you would mix `case #unknown` with
> `default` when matching against a single value.
>
>
> Brent gave a simple example down thread.  That said, I’m more concerned
> about keeping pattern matching simple and composable than I am about
> particular use cases (I agree the top level case in a switch on enum is the
> disproportionately important case).
>
> At some point we will hopefully extend pattern matching to support regexes
> and other things, we want to keep the design consistent.
>
> That said, it sounds like people are happier with `case #unknown` than
> `unknown case`, and that leaves things a little more consistent if we ever
> do expand it to other pattern positions, so I'll change the proposal
> revision to use that spelling. (And if anyone comes up with a nicer
> spelling, great!)
>
>
> Thanks!
>
> -Chris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

On Jan 9, 2018, at 4:46 PM, Jordan Rose  wrote:
> Thanks for writing this up, Chris! I addressed the idea of making this an 
> arbitrary pattern in the revised proposal 
> ,
>  and the idea of not matching known cases in a "considered alternative" 
> ,
>  but in short:
> 
> - Matching in arbitrary pattern positions is harder to implement and harder 
> to produce good diagnostics for. (Specifically, the former comes from having 
> to actually check the existing cases in the generated code rather than just 
> having an "else" branch.) I'm not inherently opposed to it if we can all 
> agree on what it means, but I don't think I have time to implement it for 
> Swift 5, so I'm not including it in the proposal.

I’m not sure what you’re saying here.  This does slot directly into the 
existing pattern design: it is just a new terminal pattern node.  Are you 
saying the SILGen/IRGen is more difficult and therefore you’re not interested 
in doing it even if it is the better design?  

If that is the case, then the conservatively correct thing to do (in my 
opinion) is to add no feature here: no “unknown case:” and no “case #unknown:’.

Alternatively are you saying that you intend to support only the “case 
#unknown:” form exactly, but not the recursive cases?

> - Matching known cases is a feature, not a limitation, to avoid existing code 
> changing meaning when you recompile. I'll admit that's not the strongest 
> motivation, though, since other things can change the meaning of existing 
> code when you recompile already.

I’m not sure I understand this. 

The whole motivation for this feature is to notify people if they are not 
handling a “newly known” case.  If they don’t care about this, they can just 
use default.

> - FWIW I can't actually think of a use case for using this with `if case` or 
> anything else. I'm not against it, but I don't know why you would ever do it, 
> just like I don't know why you would mix `case #unknown` with `default` when 
> matching against a single value.

Brent gave a simple example down thread.  That said, I’m more concerned about 
keeping pattern matching simple and composable than I am about particular use 
cases (I agree the top level case in a switch on enum is the disproportionately 
important case). 

At some point we will hopefully extend pattern matching to support regexes and 
other things, we want to keep the design consistent.

> That said, it sounds like people are happier with `case #unknown` than 
> `unknown case`, and that leaves things a little more consistent if we ever do 
> expand it to other pattern positions, so I'll change the proposal revision to 
> use that spelling. (And if anyone comes up with a nicer spelling, great!)

Thanks!

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez  wrote:
> Hi Chris,
> 
> This is great. Thanks for spending time on this! I am in favor of `case 
> #unknown` to only match unknown cases. 
> 
> 1) Would #uknown be available to RawRepresentable structs?

I haven’t considered this, so I’m not sure how that would work.  I had assumed 
that this would be an enum specific concept.

What do you have in mind?  If your raw representation is itself an enum, then 
of course this would work.

> 2) How is the #uknown pattern accomplished? Are you suggesting to capture all 
> the compile time known cases so you can do a diff during 
> runtime? (Sorry this is not obvious to me)

The internals of the compiler would handle this, it is difficult to explain 
unless you know the bowels of silgen and irgen :-)

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

On Jan 9, 2018, at 12:27 PM, Vladimir.S  wrote:
>> 2) Swift also has other facilities for pattern matching, including ‘if 
>> case’.  Making switch inconsistent with them is not great.
>> 3) As pitched, “unknown case” will match *known* cases too, which is (in my 
>> opinion :-) oxymoronic.
> 
> Are you saying here about situation, when new case is added in non-frozen 
> enum, but we are compiling the old code with absent new case but with 
> "unknown case" in switch? As stated in proposal, in this case we'll have a 
> warning exactly for source compatibility reason: "..unknown case matches any 
> value. ... the compiler will produce a warning if all known elements of the 
> enum have not already been matched. This is a warning rather than an error so 
> that adding new elements to the enum remains a source-compatible change." Do 
> you suggest to change that warning into error?
> 
> Or you are saying about another situation when “unknown case” will match 
> known cases too in the initial proposal ?

In the proposal, ‘unknown case’ is a synonym for default with changes to 
warning generation.  This means that it matches everything, including cases 
known at static compile time.

>> 4) “unknown case:” changes the basic swift grammar (it isn’t just a modifier 
>> on case) because case *requires* a pattern.   A better spelling would be 
>> “unknown default:” which is closer to the semantic provided anyway.
>> 5) It is entirely reasonable (though rare in practice) to want to handle 
>> default and unknown cases in the same switch.
> 
> Are you suggesting to have this?:
> 
> switch val {
> case .one: ...
> case .two: ...
> case #unknown: ...
> default: ..
> }

Yes.

> So, all new cases, introduced in external module after compilation of that 
> code will fall into "case #unknown: ..." bucket, but all "known"(at the 
> moment of compilation) cases but not .one/.two - into "default:..." ? 
> Personally I like that, so if I need this - I will be able to express this, 
> but that rule seems like complicated to understand.
> But this can be really helpful in situation, when you *at compilation time" 
> thinks that you are not interested in anything but .one/.two cases of that 
> enum, but in case of new values - you want to show(for example) a warning for 
> app user.

Exactly.  It is a narrow case, but it is important to me that we provide 
primitives that compose properly.

> 
> Do I understand correctly, that you suggest the same behavior as in 
> original(updated) proposal:
> * if we have a switch on non-frozen enum value, and enumerated some cases, 
> and have "case #unknown" - we'll have a warning(error?) if (at the moment of 
> compilation) not all known enums are processed in "switch” ?

Yes.

> Just to be sure.
> 
> Btw, should this be valid? :
> switch val {
>  case #unknown:... // I'm only interested if new values were added to that 
> external enum
>  default: ... // as I understand, "default" will be required here
> }

Yes, this would be very weird to write, but would be valid: the default matches 
all known cases at compile time.  I’d suggest that you write that as a “if case 
#unknown” with an else though.

-Chris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Antoine Cœur via swift-evolution]

I'm not in favor to distinguish #unknown and #known, as it may lead to
surprises, like something that previously was unknown becomes known on a
newer iOS version for instance. And version-dependant code is clearer if
solely handled by the `@available()` syntax.

I like the new pattern matching syntax proposal, but I feel it would also
work by naming it `default` instead of `unknown`:

case (_, default): …  matches any int and any unknown enum case ...


Le mer. 10 janv. 2018 à 08:46, Jordan Rose via swift-evolution <
swift-evolution@swift.org> a écrit :

>
>
> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The mega-thread about SE-0192 is a bit large, and I’d like to talk about
> one specific point.  In the review conversation, there has been significant
> objection to the idea of requiring a ‘default’ for switches over enums that
> are non-exhaustive.
>
> This whole discussion is happening because the ABI stability work is
> introducing a new concept to enums - invisible members/inhabitants (and
> making them reasonably prominent).  A closely related feature is that may
> come up in the future is "private cases”.  Private cases are orthogonal to
> API evolution and may even occur on one that is defined to be exhaustive.
>
> Private cases and non-exhaustive enums affect the enum in the same way:
> they say that the enum can have values that a client does not know about.
> Swift requires switches to process *all* of the dynamically possible
> values, which is why the original proposal started out with the simplest
> possible solution: just require ‘default' when processing the cases.
>
>
> *The problems with “unknown case:”*
>
> The popular solution to this probably is currently being pitched as a
> change to the proposal (https://github.com/apple/swift-evolution/pull/777)
> which introduces a new concept “unknown case” as a near-alias for ‘default’:
>
> https://github.com/jrose-apple/swift-evolution/blob/60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-exhaustive-enums.md#unknown-case
>
> In short, I think this is the wrong way to solve the problem.  I have
> several concerns with this:
>
> 1) Unlike in C, switch is Swift is a general pattern matching facility -
> not a way of processing integers.  It supports recursive patterns and
> values, and enums are not necessarily at the top-level of the pattern.
> https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a
> document from early evolution of Swift but contains a good general
> introduction to this.
>
> 2) Swift also has other facilities for pattern matching, including ‘if
> case’.  Making switch inconsistent with them is not great.
>
> 3) As pitched, “unknown case” will match *known* cases too, which is (in
> my opinion :-) oxymoronic.
>
> 4) “unknown case:” changes the basic swift grammar (it isn’t just a
> modifier on case) because case *requires* a pattern.  A better spelling
> would be “unknown default:” which is closer to the semantic provided anyway.
>
> 5) It is entirely reasonable (though rare in practice) to want to handle
> default and unknown cases in the same switch.
>
>
> For all the above reasons, ‘unknown case:' becomes a weird wart put on the
> side of switch/case, not something that fits in naturally with the rest of
> Swift.
>
>
> *Alternative proposal:*
>
> Instead of introducing a new modifier on case/switch, lets just introduce
> a new pattern matching operator that *matches unknown cases*, called
> “#unknown” or “.#unknown” or something (I’m not wed to the syntax, better
> suggestions welcome :).
>
> In the simple case most people are talking about, instead of writing
> “unknown case:” you’d write “case #unknown:” which isn’t much different.
> The nice thing about this is that #unknown slots directly into our pattern
> matching system.  Here is a weird example:
>
> switch someIntEnumTuple {
> case (1, .X):   … matches one combination of int and tuple...
> case (2, .Y):   … matches another combination of int and tuple...
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case default:  … matches anything ...
> }
>
> Furthermore, if you have a switch that enumerates all of the known cases
> and use #unknown, then it falls out of the model that new cases (e.g. due
> to an SDK upgrade or an updated source package) produces the existing build
> error.  As with the original proposal, you can always choose to use
> “default:” instead of “case #unknown:” if you don’t like that behavior.
>
> Of course, if you have an exhaustive enum (e.g. one defined in your own
> module or explicitly marked as such) then #unknown matches nothing, so we
> should warn about it being pointless.
>
>
> This addresses my concerns above:
>
> 1) This fits into patterns in recursive positions, and slots directly into
> the existing grammar for patterns.  It would be a very simple extension to
> the compiler instead of a special case added to switch/case.
>

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Brent Royal-Gordon via swift-evolution]

> On Jan 9, 2018, at 4:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> - FWIW I can't actually think of a use case for using this with `if case` or 
> anything else. I'm not against it, but I don't know why you would ever do it, 
> just like I don't know why you would mix `case #unknown` with `default` when 
> matching against a single value.

if case #unknown = someEnum {
throw MyError.unknownValue
}
…

> That said, it sounds like people are happier with `case #unknown` than 
> `unknown case`, and that leaves things a little more consistent if we ever do 
> expand it to other pattern positions, so I'll change the proposal revision to 
> use that spelling. (And if anyone comes up with a nicer spelling, great!)

I don't love the spelling of `#unknown`—particularly since some enums in the 
Apple frameworks actually *have* an ordinary case called "unknown"—but I think 
it's a nice, pragmatic solution which slots into pattern matching very nicely.

(And if we ever *do* decide to support @testable enum parameters, we'll already 
have the syntax to specify unknown values.)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose via swift-evolution]

> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution 
>  wrote:
> 
> The mega-thread about SE-0192 is a bit large, and I’d like to talk about one 
> specific point.  In the review conversation, there has been significant 
> objection to the idea of requiring a ‘default’ for switches over enums that 
> are non-exhaustive.  
> 
> This whole discussion is happening because the ABI stability work is 
> introducing a new concept to enums - invisible members/inhabitants (and 
> making them reasonably prominent).  A closely related feature is that may 
> come up in the future is "private cases”.  Private cases are orthogonal to 
> API evolution and may even occur on one that is defined to be exhaustive.
> 
> Private cases and non-exhaustive enums affect the enum in the same way: they 
> say that the enum can have values that a client does not know about.  Swift 
> requires switches to process *all* of the dynamically possible values, which 
> is why the original proposal started out with the simplest possible solution: 
> just require ‘default' when processing the cases.
> 
> 
> The problems with “unknown case:”
> 
> The popular solution to this probably is currently being pitched as a change 
> to the proposal (https://github.com/apple/swift-evolution/pull/777 
> ) which introduces a new 
> concept “unknown case” as a near-alias for ‘default’:
> https://github.com/jrose-apple/swift-evolution/blob/60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-exhaustive-enums.md#unknown-case
>  
> 
> 
> In short, I think this is the wrong way to solve the problem.  I have several 
> concerns with this:
> 
> 1) Unlike in C, switch is Swift is a general pattern matching facility - not 
> a way of processing integers.  It supports recursive patterns and values, and 
> enums are not necessarily at the top-level of the pattern.   
> https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a 
> document from early evolution of Swift but contains a good general 
> introduction to this.
> 
> 2) Swift also has other facilities for pattern matching, including ‘if case’. 
>  Making switch inconsistent with them is not great.
> 
> 3) As pitched, “unknown case” will match *known* cases too, which is (in my 
> opinion :-) oxymoronic.
> 
> 4) “unknown case:” changes the basic swift grammar (it isn’t just a modifier 
> on case) because case *requires* a pattern.  A better spelling would be 
> “unknown default:” which is closer to the semantic provided anyway.
> 
> 5) It is entirely reasonable (though rare in practice) to want to handle 
> default and unknown cases in the same switch.
> 
> 
> For all the above reasons, ‘unknown case:' becomes a weird wart put on the 
> side of switch/case, not something that fits in naturally with the rest of 
> Swift.
> 
> 
> Alternative proposal:
> 
> Instead of introducing a new modifier on case/switch, lets just introduce a 
> new pattern matching operator that *matches unknown cases*, called “#unknown” 
> or “.#unknown” or something (I’m not wed to the syntax, better suggestions 
> welcome :).
> 
> In the simple case most people are talking about, instead of writing “unknown 
> case:” you’d write “case #unknown:” which isn’t much different.  The nice 
> thing about this is that #unknown slots directly into our pattern matching 
> system.  Here is a weird example:
> 
> switch someIntEnumTuple {
> case (1, .X):   … matches one combination of int and tuple...
> case (2, .Y):   … matches another combination of int and tuple...
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case default:  … matches anything ...
> }
> 
> Furthermore, if you have a switch that enumerates all of the known cases and 
> use #unknown, then it falls out of the model that new cases (e.g. due to an 
> SDK upgrade or an updated source package) produces the existing build error.  
> As with the original proposal, you can always choose to use “default:” 
> instead of “case #unknown:” if you don’t like that behavior.
> 
> Of course, if you have an exhaustive enum (e.g. one defined in your own 
> module or explicitly marked as such) then #unknown matches nothing, so we 
> should warn about it being pointless.
> 
> 
> This addresses my concerns above:
> 
> 1) This fits into patterns in recursive positions, and slots directly into 
> the existing grammar for patterns.  It would be a very simple extension to 
> the compiler instead of a special case added to switch/case.
> 
> 2) Because it slots into the pattern grammar, it works directly with 'if 
> case’ and the other pattern matching stuff.
> 
> 3) Doesn’t match known cases.
> 
> 4) Doesn’t change the case grammar, it just adds a new pattern terminal 
> production.
> 
> 5) Allows weird cases like the example 

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jose Cheyo Jimenez via swift-evolution]

Hi Chris,

This is great. Thanks for spending time on this! I am in favor of `case
#unknown` to only match unknown cases.

1) Would #uknown be available to RawRepresentable structs?

2) How is the #uknown pattern accomplished? Are you suggesting to capture
all the compile time known cases so you can do a diff during
runtime? (Sorry this is not obvious to me)

Previously I suggested having something like `case #known` that would only
match known cases by capturing known cases at compile time ( maybe using a
compile-time variation of
https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md).
This would give us the equivalent of `case _` == `case #known` + `case
#unknown`.  The only issue I found with `case #known`  is that it would be
the same as `case _` when working with an exhaustive enum.

switch myEnum{
case .X :   //
case .Y :   //
case #unknown : // Matches all runtime unknown cases
case #known : //  Matches all compile known cases
}

On Mon, Jan 8, 2018 at 10:54 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> The mega-thread about SE-0192 is a bit large, and I’d like to talk about
> one specific point.  In the review conversation, there has been significant
> objection to the idea of requiring a ‘default’ for switches over enums that
> are non-exhaustive.
>
> This whole discussion is happening because the ABI stability work is
> introducing a new concept to enums - invisible members/inhabitants (and
> making them reasonably prominent).  A closely related feature is that may
> come up in the future is "private cases”.  Private cases are orthogonal to
> API evolution and may even occur on one that is defined to be exhaustive.
>
> Private cases and non-exhaustive enums affect the enum in the same way:
> they say that the enum can have values that a client does not know about.
> Swift requires switches to process *all* of the dynamically possible
> values, which is why the original proposal started out with the simplest
> possible solution: just require ‘default' when processing the cases.
>
>
> *The problems with “unknown case:”*
>
> The popular solution to this probably is currently being pitched as a
> change to the proposal (https://github.com/apple/swift-evolution/pull/777)
> which introduces a new concept “unknown case” as a near-alias for ‘default’:
> https://github.com/jrose-apple/swift-evolution/blob/
> 60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-
> exhaustive-enums.md#unknown-case
>
> In short, I think this is the wrong way to solve the problem.  I have
> several concerns with this:
>
> 1) Unlike in C, switch is Swift is a general pattern matching facility -
> not a way of processing integers.  It supports recursive patterns and
> values, and enums are not necessarily at the top-level of the pattern.
> https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a
> document from early evolution of Swift but contains a good general
> introduction to this.
>
> 2) Swift also has other facilities for pattern matching, including ‘if
> case’.  Making switch inconsistent with them is not great.
>
> 3) As pitched, “unknown case” will match *known* cases too, which is (in
> my opinion :-) oxymoronic.
>
> 4) “unknown case:” changes the basic swift grammar (it isn’t just a
> modifier on case) because case *requires* a pattern.  A better spelling
> would be “unknown default:” which is closer to the semantic provided anyway.
>
> 5) It is entirely reasonable (though rare in practice) to want to handle
> default and unknown cases in the same switch.
>
>
> For all the above reasons, ‘unknown case:' becomes a weird wart put on the
> side of switch/case, not something that fits in naturally with the rest of
> Swift.
>
>
> *Alternative proposal:*
>
> Instead of introducing a new modifier on case/switch, lets just introduce
> a new pattern matching operator that *matches unknown cases*, called
> “#unknown” or “.#unknown” or something (I’m not wed to the syntax, better
> suggestions welcome :).
>
> In the simple case most people are talking about, instead of writing
> “unknown case:” you’d write “case #unknown:” which isn’t much different.
> The nice thing about this is that #unknown slots directly into our pattern
> matching system.  Here is a weird example:
>
> switch someIntEnumTuple {
> case (1, .X):   … matches one combination of int and tuple...
> case (2, .Y):   … matches another combination of int and tuple...
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case default:  … matches anything ...
> }
>
> Furthermore, if you have a switch that enumerates all of the known cases
> and use #unknown, then it falls out of the model that new cases (e.g. due
> to an SDK upgrade or an updated source package) produces the existing build
> error.  As with the original proposal, you can always choose to use
> “default:” instead of “case #unknown:” if you don’t like that behavior.
>
> Of course, 

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Richard Wei via swift-evolution]

Something like `#unknown` or `#undiscovered` in the pattern matching syntax 
makes complete sense.

-Richard

> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution 
>  wrote:
> 
> The mega-thread about SE-0192 is a bit large, and I’d like to talk about one 
> specific point.  In the review conversation, there has been significant 
> objection to the idea of requiring a ‘default’ for switches over enums that 
> are non-exhaustive.
> 
> This whole discussion is happening because the ABI stability work is 
> introducing a new concept to enums - invisible members/inhabitants (and 
> making them reasonably prominent).  A closely related feature is that may 
> come up in the future is "private cases”.  Private cases are orthogonal to 
> API evolution and may even occur on one that is defined to be exhaustive.
> 
> Private cases and non-exhaustive enums affect the enum in the same way: they 
> say that the enum can have values that a client does not know about.  Swift 
> requires switches to process *all* of the dynamically possible values, which 
> is why the original proposal started out with the simplest possible solution: 
> just require ‘default' when processing the cases.
> 
> 
> The problems with “unknown case:”
> 
> The popular solution to this probably is currently being pitched as a change 
> to the proposal (https://github.com/apple/swift-evolution/pull/777 
> ) which introduces a new 
> concept “unknown case” as a near-alias for ‘default’:
> https://github.com/jrose-apple/swift-evolution/blob/60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-exhaustive-enums.md#unknown-case
>  
> 
> 
> In short, I think this is the wrong way to solve the problem.  I have several 
> concerns with this:
> 
> 1) Unlike in C, switch is Swift is a general pattern matching facility - not 
> a way of processing integers.  It supports recursive patterns and values, and 
> enums are not necessarily at the top-level of the pattern.   
> https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a 
> document from early evolution of Swift but contains a good general 
> introduction to this.
> 
> 2) Swift also has other facilities for pattern matching, including ‘if case’. 
>  Making switch inconsistent with them is not great.
> 
> 3) As pitched, “unknown case” will match *known* cases too, which is (in my 
> opinion :-) oxymoronic.
> 
> 4) “unknown case:” changes the basic swift grammar (it isn’t just a modifier 
> on case) because case *requires* a pattern.  A better spelling would be 
> “unknown default:” which is closer to the semantic provided anyway.
> 
> 5) It is entirely reasonable (though rare in practice) to want to handle 
> default and unknown cases in the same switch.
> 
> 
> For all the above reasons, ‘unknown case:' becomes a weird wart put on the 
> side of switch/case, not something that fits in naturally with the rest of 
> Swift.
> 
> 
> Alternative proposal:
> 
> Instead of introducing a new modifier on case/switch, lets just introduce a 
> new pattern matching operator that *matches unknown cases*, called “#unknown” 
> or “.#unknown” or something (I’m not wed to the syntax, better suggestions 
> welcome :).
> 
> In the simple case most people are talking about, instead of writing “unknown 
> case:” you’d write “case #unknown:” which isn’t much different.  The nice 
> thing about this is that #unknown slots directly into our pattern matching 
> system.  Here is a weird example:
> 
> switch someIntEnumTuple {
> case (1, .X):   … matches one combination of int and tuple...
> case (2, .Y):   … matches another combination of int and tuple...
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case default:  … matches anything ...
> }
> 
> Furthermore, if you have a switch that enumerates all of the known cases and 
> use #unknown, then it falls out of the model that new cases (e.g. due to an 
> SDK upgrade or an updated source package) produces the existing build error.  
> As with the original proposal, you can always choose to use “default:” 
> instead of “case #unknown:” if you don’t like that behavior.
> 
> Of course, if you have an exhaustive enum (e.g. one defined in your own 
> module or explicitly marked as such) then #unknown matches nothing, so we 
> should warn about it being pointless.
> 
> 
> This addresses my concerns above:
> 
> 1) This fits into patterns in recursive positions, and slots directly into 
> the existing grammar for patterns.  It would be a very simple extension to 
> the compiler instead of a special case added to switch/case.
> 
> 2) Because it slots into the pattern grammar, it works directly with 'if 
> case’ and the other pattern matching stuff.
> 
> 3) Doesn’t match known cases.
> 
> 4) Doesn’t change the 

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Vladimir.S via swift-evolution]

Hi Chris, thank you for the new idea!

FWIW, after first reading, it looks like more elegant solution than "unknown case" in initial proposal. Swift's enums 
deserve powerful and flexible solution!


I really like the syntax of

switch val {
case .one: ...
case .two: ...
case #unknown: ...
}

instead of

switch val {
case .one: ...
case .two: ...
unknown case: ...
}

Also the possibility to use the #unknown in pattern matching is awesome.

Please find some comments/questions inline:

On 09.01.2018 9:54, Chris Lattner via swift-evolution wrote:
The mega-thread about SE-0192 is a bit large, and I’d like to talk about one specific point.  In the review 
conversation, there has been significant objection to the idea of requiring a ‘default’ for switches over enums that are 
non-exhaustive.


This whole discussion is happening because the ABI stability work is introducing a new concept to enums - invisible 
members/inhabitants (and making them reasonably prominent).  A closely related feature is that may come up in the future 
is "private cases”.  Private cases are orthogonal to API evolution and may even occur on one that is defined to be 
exhaustive.


Private cases and non-exhaustive enums affect the enum in the same way: they say that the enum can have values that a 
client does not know about.  Swift requires switches to process *all* of the dynamically possible values, which is why 
the original proposal started out with the simplest possible solution: just require ‘default' when processing the cases.



*The problems with “unknown case:”*

The popular solution to this probably is currently being pitched as a change to the proposal 
(https://github.com/apple/swift-evolution/pull/777) which introduces a new concept “unknown case” as a near-alias for 
‘default’:

https://github.com/jrose-apple/swift-evolution/blob/60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-exhaustive-enums.md#unknown-case

In short, I think this is the wrong way to solve the problem.  I have several 
concerns with this:

1) Unlike in C, switch is Swift is a general pattern matching facility - not a way of processing integers.  It supports 
recursive patterns and values, and enums are not necessarily at the top-level of the pattern.   
https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a document from early evolution of Swift but 
contains a good general introduction to this.


2) Swift also has other facilities for pattern matching, including ‘if case’.  Making switch inconsistent with them is 
not great.


3) As pitched, “unknown case” will match *known* cases too, which is (in my 
opinion :-) oxymoronic.


Are you saying here about situation, when new case is added in non-frozen enum, but we are compiling the old code with 
absent new case but with "unknown case" in switch? As stated in proposal, in this case we'll have a warning exactly for 
source compatibility reason: "..unknown case matches any value. ... the compiler will produce a warning if all known 
elements of the enum have not already been matched. This is a warning rather than an error so that adding new elements 
to the enum remains a source-compatible change." Do you suggest to change that warning into error?


Or you are saying about another situation when “unknown case” will match known 
cases too in the initial proposal ?




4) “unknown case:” changes the basic swift grammar (it isn’t just a modifier on case) because case *requires* a pattern. 
  A better spelling would be “unknown default:” which is closer to the semantic provided anyway.


5) It is entirely reasonable (though rare in practice) to want to handle 
default and unknown cases in the same switch.



Are you suggesting to have this?:

switch val {
case .one: ...
case .two: ...
case #unknown: ...
default: ..
}

So, all new cases, introduced in external module after compilation of that code will fall into "case #unknown: ..." 
bucket, but all "known"(at the moment of compilation) cases but not .one/.two - into "default:..." ? Personally I like 
that, so if I need this - I will be able to express this, but that rule seems like complicated to understand.


But this can be really helpful in situation, when you *at compilation time" thinks that you are not interested in 
anything but .one/.two cases of that enum, but in case of new values - you want to show(for example) a warning for app user.




For all the above reasons, ‘unknown case:' becomes a weird wart put on the side of switch/case, not something that fits 
in naturally with the rest of Swift.



*Alternative proposal:*

Instead of introducing a new modifier on case/switch, lets just introduce a new pattern matching operator that *matches 
unknown cases*, called “#unknown” or “.#unknown” or something (I’m not wed to the syntax, better suggestions welcome :).


In the simple case most people are talking about, instead of writing “unknown case:” you’d write “case #unknown:” which 
isn’t much different.  The nice thing 

[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Chris Lattner via swift-evolution]

The mega-thread about SE-0192 is a bit large, and I’d like to talk about one 
specific point.  In the review conversation, there has been significant 
objection to the idea of requiring a ‘default’ for switches over enums that are 
non-exhaustive.  

This whole discussion is happening because the ABI stability work is 
introducing a new concept to enums - invisible members/inhabitants (and making 
them reasonably prominent).  A closely related feature is that may come up in 
the future is "private cases”.  Private cases are orthogonal to API evolution 
and may even occur on one that is defined to be exhaustive.

Private cases and non-exhaustive enums affect the enum in the same way: they 
say that the enum can have values that a client does not know about.  Swift 
requires switches to process *all* of the dynamically possible values, which is 
why the original proposal started out with the simplest possible solution: just 
require ‘default' when processing the cases.


The problems with “unknown case:”

The popular solution to this probably is currently being pitched as a change to 
the proposal (https://github.com/apple/swift-evolution/pull/777) which 
introduces a new concept “unknown case” as a near-alias for ‘default’:
https://github.com/jrose-apple/swift-evolution/blob/60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-exhaustive-enums.md#unknown-case

In short, I think this is the wrong way to solve the problem.  I have several 
concerns with this:

1) Unlike in C, switch is Swift is a general pattern matching facility - not a 
way of processing integers.  It supports recursive patterns and values, and 
enums are not necessarily at the top-level of the pattern.   
https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a 
document from early evolution of Swift but contains a good general introduction 
to this.

2) Swift also has other facilities for pattern matching, including ‘if case’.  
Making switch inconsistent with them is not great.

3) As pitched, “unknown case” will match *known* cases too, which is (in my 
opinion :-) oxymoronic.

4) “unknown case:” changes the basic swift grammar (it isn’t just a modifier on 
case) because case *requires* a pattern.  A better spelling would be “unknown 
default:” which is closer to the semantic provided anyway.

5) It is entirely reasonable (though rare in practice) to want to handle 
default and unknown cases in the same switch.


For all the above reasons, ‘unknown case:' becomes a weird wart put on the side 
of switch/case, not something that fits in naturally with the rest of Swift.


Alternative proposal:

Instead of introducing a new modifier on case/switch, lets just introduce a new 
pattern matching operator that *matches unknown cases*, called “#unknown” or 
“.#unknown” or something (I’m not wed to the syntax, better suggestions welcome 
:).

In the simple case most people are talking about, instead of writing “unknown 
case:” you’d write “case #unknown:” which isn’t much different.  The nice thing 
about this is that #unknown slots directly into our pattern matching system.  
Here is a weird example:

switch someIntEnumTuple {
case (1, .X):   … matches one combination of int and tuple...
case (2, .Y):   … matches another combination of int and tuple...
case (_, #unknown): …  matches any int and any unknown enum case ...
case default:  … matches anything ...
}

Furthermore, if you have a switch that enumerates all of the known cases and 
use #unknown, then it falls out of the model that new cases (e.g. due to an SDK 
upgrade or an updated source package) produces the existing build error.  As 
with the original proposal, you can always choose to use “default:” instead of 
“case #unknown:” if you don’t like that behavior.

Of course, if you have an exhaustive enum (e.g. one defined in your own module 
or explicitly marked as such) then #unknown matches nothing, so we should warn 
about it being pointless.


This addresses my concerns above:

1) This fits into patterns in recursive positions, and slots directly into the 
existing grammar for patterns.  It would be a very simple extension to the 
compiler instead of a special case added to switch/case.

2) Because it slots into the pattern grammar, it works directly with 'if case’ 
and the other pattern matching stuff.

3) Doesn’t match known cases.

4) Doesn’t change the case grammar, it just adds a new pattern terminal 
production.

5) Allows weird cases like the example above.


All that said, the #unknown spelling isn’t great, but I’m sure we can find 
something else nice.

Thoughts?

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution