> On Jan 10, 2018, at 1:29 PM, Dave DeLong via swift-evolution 
> <swift-evolution@swift.org> wrote:
>> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@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 
>> <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.

swift-evolution mailing list

Reply via email to