> 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.
Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
