[swift-evolution] Handling unknown cases in enums [RE: SE-0192]
matthew at anandabits.com
Fri Jan 12 19:50:25 CST 2018
> On Jan 12, 2018, at 6:31 PM, Jonathan Hull via swift-evolution <swift-evolution at 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.
>> On Jan 12, 2018, at 3:08 PM, Jordan Rose via swift-evolution <swift-evolution at 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.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution