-1. I agree this is a problem, but I think this is the wrong solution. I think the solution should be on the client side, not on the framework author’s side.
I would be fine if enums from imported modules are non-exhaustive, as long as I can choose to treat them as exhaustive if I want to. And in that case, if a new case is introduced, I think a fatal error is a reasonable result. The proposed “switch!” command would do just this, and I think that is the better answer for this. Adding an @exhaustive attribute doesn’t actually prevent someone from adding a case anyway, which I think is a big (and not really solvable) issue 🤷♂️ I know much has been said about this, but it’s just my 2c. > On Dec 27, 2017, at 9:42 AM, Thorsten Seitz via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> The proposal is available here: >> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md >> What is your evaluation of the proposal? >> > > -1 > > I would much prefer the solution proposed by Andrew Bennett in another thread > which solves all problems very nicely including the testability of future > cases by giving them a placeholder name: > > From Andrew’s mail: >> public enum HomeworkExcuse { >> case eatenByPet >> case thoughtItWasDueNextWeek >> fallback unknown // NEW >> } >> >> Then I believe you would be able to have an exhaustive switch like this: >> >> switch thing { >> case eatenByPet: break >> case thoughtItWasDueNextWeek: break >> case unknown: break >> } >> >> Which would still allow compile-time errors if new cases are introduced, >> while providing a concise way to show something is not exhaustible. >> >> This would also support existing enums with "unknown" equivalent cases would >> be able to explicitly label those fields as fallback without needing to make >> large code changes. >> >> I see no reason why you shouldn't be able to use ".unknown", which should >> still allow this to be testable. > > i.e. Andrew’s idea is to introduce a placeholder case instead of marking the > enum as exhaustive/non-exhaustive. This gives the future cases a handle to be > switched on and to be tested against. Very elegant. > >> Is the problem being addressed significant enough to warrant a change to >> Swift? >> > Yes, but the proposed solution is not as good as it should be, neglecting to > provide compile-time errors if new cases are introduced. >> Does this proposal fit well with the feel and direction of Swift? >> > No, due to its shortcomings. >> If you have used other languages or libraries with a similar feature, how do >> you feel that this proposal compares to those? >> > None, but see Andrew Bennett’s idea above. >> How much effort did you put into your review? A glance, a quick reading, or >> an in-depth study? >> > Followed most of the discussion and review threads. > > -Thorsten > _______________________________________________ > 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
