> Le 28 déc. 2017 à 21:17, Eneko Alonso via swift-evolution > <swift-evolution@swift.org> a écrit : > > 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?
IIUC, this is to help binary stability. If a library developer write an enum without knowing about « @exhaustive », it can safely add another enum in a v2 of the library without breaking all the clients. > > 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 <mailto: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 <mailto: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