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