> I am part of the people mentioned in "Preserve exhaustiveness diagnostics for > non-exhaustive enums" : I see the completeness check as a major feature of > enums, that makes a difference between it and a list of constants in multiple > cases. > So much that in the coding rules of the company I work for, the use of > default case requires some specific justification at review time.
Standing ovation :), one of my most loved warnings in -Weverything was ensuring switches were exhaustive. I quite disagree with being unnecessarily strict with making classes closed by default and è una non exhaustive by default and potentially tons of unchecked changes ended up in the default case with the “hey, we can force it to be exhaustive in the unit tests”. I particularly dislike that line of reasoning in a language about strong static typing as “well, write unit tests to get your correctness and safety tests” is the JavaScript mantra (of those that see TypeScript as pure evil). > I have a positive opinion on this evolution if it comes with a solution to > preserve exhaustiveness diagnostics. Otherwise, I think it lowers the ease of > maintenance of code using external libraries. > > One of the risk I fear is that libraries builders might just forget to add > the @exhaustive keyword. So it might end up being a pretty common case to > have to specify "I want this switch to be exhaustive", just to not loose on > maintainability. This could lead to a situation similar to the "fileprivate", > that ended up being used much more than expected. > > It is not exactly in the scope of that review, but in the two solution for > enforcing exhaustiveness drafted in that proposal, I would rather avoid the > second one (the switch!). It would contradict the fact that as of today, the > use of the exclamation mark in swift is a pretty clear sign that you are > disabling some compiler-provided security at your own risk, and that it might > lead to runtime crash (force unwrap, force cast, ...). > Here, requesting a switch to be exhaustive is adding one more compiler check. > It cannot lead to a runtime crash. > I will be happy to discuss it further in a future review. > > Jerome > _______________________________________________ > 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
