[swift-evolution] Enums and Source Compatibility

[Rod Brown]

> On 8 Sep 2017, at 2:55 am, Vladimir.S <svabox at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170908/7e4d2f7b/attachment.html>