Actually, from the other email thread about this same topic (thank god forums are almost here), I see the proposed syntax “final switch” for what I referred to as “switch!”, which I prefer.
> On Dec 28, 2017, at 12:17 AM, Riley Testut via swift-evolution > <swift-evolution@swift.org> wrote: > > -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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
