Hello everyone, My name is Eneko Alonso, iOS developer, new here on the list.
Is there a good summary anywhere that condenses the pros and cons of this new feature that have been discussed so far? It is not clear to me why non-exhaustive would be the default, requiring adding `@exhaustive` otherwise. Has anyone discussed doing it the other way around, this is, defaulting to exhaustive (no changes with prior Swift versions) and adding a `@nonExhaustive` tag instead as needed? Apologies if this has been covered already. Regards and thank you everyone for making Swift better! Eneko > On Dec 27, 2017, at 10:26 PM, Riley Testut via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 <mailto: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 <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> >>>> The proposal is available here: >>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md >>>> >>>> <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 <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
