[swift-evolution] Enums and Source Compatibility

[Rod Brown]

> On 8 Sep 2017, at 12:24 am, Vladimir.S <svabox at gmail.com> wrote:
> 
> 
> 
> On 07.09.2017 16:03, Rod Brown wrote:
>>> On 7 Sep 2017, at 9:26 pm, Vladimir.S via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> Just small note. As I understand, this is a source breaking suggestion, no?
>>> I mean any client code for 'public enum' coming from another module, will have to add 'default' case in 'switch'. So, the previously correct code will not compile. Or do you suggest to raise a warning only for the first time and raise an error in next version of Swift?
>> Yes. By defaulting to “non fragile” we add a source incompatibility, because Swift is currently assuming fragility. In Jordan’s proposal, it is assuming fragility/exhaustive by default, and therefore would be source compatible. Good point.
>> I keep wavering back and forth on the importance of Source Compatibility with this one. Defaulting to “exhaustive” seems dangerous to me. It makes your framework (and future versions of it) fragile without ever having to think about it. At least if the keyword of “exhaustive” or “fragile” or “sealed” meant that you actively chose the fragility that will handcuff you later down the road.
> 
> Yes, probably(still thinking about this) I agree that 'open'('exhaustive') enum should be the default for public enum; and only if author is really sure enum will not change in future and to provide a space for compiler's optimizations and suggest client to switch exhaustive, he/she can mark such enum as exhaustive/fragile/sealed/closed/fixed. And seems like the right direction is raise warnings fist, and errors in next version of Swift.
> 
> The only question I can't find strong answer for, what my code(as a client of 'open' enum) will do in 'default' case? Will it be in 95% cases the fatalError().. If so, what is the difference with current situation?
> If my switch is already exhaustive regarding some public(imported) enum, so I'm processing all the possible *at the compilation time* cases - most likely I'll have just fatalError() in 'default'.
> If my switch already contains 'default' - the proposed change will not affect me at all…

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.

> 
> But probably it is better to have a choice what to do with future cases, than have just one direction - crash at run time if new case in external enum is added.
> 
> But the same I can say for proposed 'future' case : it is better to have a choice what to use - 'default', if we don't need to be exhaustive on 'open' enum,  or 'future', if we need to be exhaustive on 'open' enum in compile-time but separately process all future cases.

“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.

> 
> Yes, in this case we have a problem with testability, but the same is true for exhaustive switch with 'defailt' case - how this 'default' code can be tested? Probably, we need to provide a solution for this in any case, not because of 'future' but also for 'default' in exhaustive switch on 'open' enum. (Don't know how this could be implemented, probably by somehow be able to extend the imported open enum with 'fake' case when compile in special mode for testing and be able to send this fake case into tested code)

Yes, testing this is a concern. I agree: have an ability to add an “other" case in tests.

> 
> Vladimir.
> 
>>> 
>>>> 3. fragile public enum: cases may not be added, because that would break the fragility guarantee.  As such, clients within or outside of hte current module may exhaustively match against the enum.
>>> 
>>> I think 'fragile' word does not reflect what is guaranteed for this enum. The author guaranteed that this enum will not be changed, not "this enum can broke your code". Can't we use 'sealed'/'closed'/'fixed' here?
>>> 
>>> Vladimir.