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

[Howard Lovatt]

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 <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Jan 10, 2018, at 1:29 PM, Dave DeLong via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>>> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/57610553/attachment.html>