> On Jan 10, 2018, at 1:05 PM, Jordan Rose via swift-evolution
> <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.
Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
