> On Jan 12, 2018, at 6:31 PM, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> wrote: > > I’m definitely in the error camp, but I will go along with a warning if > everyone feels that is better.
I see advantages both ways. The fact that the error approach generalizes much cleaner is definitely a plus. The primary downside to that approach is losing the ability to rebuild with the same version of a source dependency that has used #unkown when matching a non-frozen enum vended by a common dependency to which a case has been added since the source dependency was written. Requiring this behavior can be viewed as a pretty significant downside. It tightens the coupling between versions of dependencies. This can make it difficult to update dependencies in a large project. The warning approach allows people to opt-in to this behavior by treating warnings as errors without requiring everyone to make the same tradeoff. It’s really a tough tradeoff. > > Thanks, > Jon > >> On Jan 12, 2018, at 3:08 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's >> point very specifically: if the compiler emits an error, we should go with >> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.) >> >> I think the revised proposal is in good shape! >> (https://github.com/apple/swift-evolution/pull/777) I think I've addressed >> everyone's feedback either in the proposal or on-list, if not necessarily >> convinced them. If there are no other major comments I'll let Ted know that >> it's ready to re-run on Monday. >> >> Jordan >> _______________________________________________ >> 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
