> On 8 Sep 2017, at 2:55 am, Vladimir.S <[email protected]> wrote: > > On 07.09.2017 18:23, Rod Brown wrote: >> >> This was discussed earlier. As I mentioned, we should be realistic: it’s >> rarely a >> truly fatal error when you get an unknown enum. Unless you really can’t find >> a >> reasonable default, then there are almost always reasonable logical ways to >> handle >> it (perhaps just breaking out?). And in cases where you really need to >> handle each >> case, this would (almost?) always be an exhaustive enum. I can’t even >> imagine the >> case where it would be so critical you couldn’t handle it with reasonable >> control >> flow. There are always solutions like returning early, breaking out, default >> details. I see Swift code littered with fatalError() not because its needed, >> but >> because the developer often didn’t care enough to think it through. > > Thank you for replies, Rod! > > Thinking about this, if "in cases where you really need to handle each case, > this would (almost?) always be an exhaustive enum", then I tend to agree with > you. > > So, currently my point of view is that we need to move the way suggested by > Chris, when we need to mark public 'closed' enum, so 'open' is default, and > with warning for first time and with error in next version of Swift for > switches on 'open' enum without 'default' case. Not the way described in the > proposal itself.
Agreed, though we shouldn't use “open/closed” as discussed in the proposal draft. > >> “Future” might be a decent idea, but I think we’re overcomplicating it. Just >> use >> “default” as we always have? “Future” as a word doesn’t seem to apply, as I >> have >> mentioned earlier: there are cases where your framework has a private case >> on an >> enum. This isn’t necessarily a future case - it could be “current”. If we >> were to >> do this, it would make more sense to call this case word “other” instead. >> Again, >> though, we’re adding complexity to a switch for a very rare case and a >> little bit >> of developer convenience in that case. > > Well... yes, seems like this. I didn't get current but private cases into > account. But I was more focused on Swift's enums, not on C's. > > What do you(and others) think about such idea: if we have an exhaustive > switch on _open_ enum _without_ 'default' case, and there are *no* more known > available cases for this enum currently - compiler generates error/warning > like "you have exhaustive switch but this is an open enum new cases can be > added later, so add 'default' case to process them". But, if such(exhaustive > on _open_ enum _without_ 'default' case) switch contains not all known cases, > warning/error will be different like "you have not exhaustive switch on open > enum, add 'default' case to process all others and future cases”. I agree. This is going to be a confusing case, especially when transitioning. Stating clearly why they need a default clause despite the “appearance” of exhaustively handling all cases should be part of the error wording. > > I believe that with this accepted proposal, if you ever will need to keep > switch exhaustive on 'open' enum, support this code, this will be a nightmare > without at least such warnings, when you can comment the 'default' case in > switch and check(by warning/error message) if you processed all the cases or > missed some. Otherwise, the alternative, is to manually check one-by-one what > you have in your switch and what cases are in enum(in case you have new > version of enum's module). > > Vladimir.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
