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! 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 mailing list

Reply via email to