[swift-evolution] Enums and Source Compatibility

[Jordan Rose]

> On Aug 11, 2017, at 02:59, Vladimir.S <svabox at gmail.com> wrote:
> 
> On 11.08.2017 2:37, Jordan Rose wrote:
>> Both you and Vladimir are bringing up this point, with Vladimir explicitly suggesting a "future" case that's different from "default". Again, the pushback we get here is that the "future" case is untestable…but maybe that's still an option worth having. 
> 
> I wonder, how the 'default' in exhaustive switch on open enum is testable?
> 
> I mean, let's say we have such enum in one of the frameworks:
> 
> open enum MyOpenEnum {
>  case one
>  case two
> }
> 
> , then in our code:
> 
> switch myOpenEnumInstance {
>  case .one : ...
>  case .two : ...
>  default : ... // how this can be tested?
> }
> 
> I just strongly feel that be able to keep switch exhaustive at the moment of compilation - is critical requirement in some cases, when it is very important to not forget to process some cases. With just 'default' in switch for open enum - we are loosing this compiler's help. This is why 'future' case is required for open enums.
> 
> Also, if I understand correctly, we are going to have most of all extern(imported) enums as 'open'. So, we are loosing the feature to receive a help for exhaustive switch from compiler for most of such enums.

That's true, but I don't know what to do about it. My hypothesis, again, is that this won't be common in practice; so far Charlie's been the only one to provide a real-world example of when this is useful.


> Moreover, shouldn't we just say that enums, that we have no Swift sources for at the moment of compilation - should *always* be treated as 'open'? If we compile our 'switch' together with the source of switched enum - such enum can not be changed in the future.
> But, if enum is coming from other framework - we have no any control over it, and even author of framework IMO can't be sure in most cases that enum will not be extended in future, and probably we even should not ask author of framework to consider its enum closed, as most likely one can't foresee for sure.
> 
> Wouldn't this be a simpler and more robust model to think about enums in Swift?
> So you know, that *any* enum coming from framework(not from source) - can be changed in future, and so you have to process this case explicitly. In this case we don't need to mark enum as 'open' or 'closed' at all, but for some rare cases, when author of framework *really sure* enum can not be changed in future(and future change in enum will break all the code depending on it), we can introduce some 'final' marker(or @exhaustive directive) to help compiler's optimizations.

Again, some enums really do want to be exhaustive: Foundation.ComparisonResult, Swift.Optional, and in general anything the framework owner really does want people to exhaustively switch over. These aren't just optimization concerns because they affect how people are expected to use the type. I think this all just means that you're on the side that "open" should be the default.


> 
> Btw, is open enum is allowed to change the type of associated value for some cases or even enum's raw type? I.e. what changes in open enum will lead to crash in our code and which will just be processed in 'default'/'future' block in switch?

Nope, that's not planned to be allowed. That would break source compatibility outside of just switch—it would also affect `if case` as well as the creation of an enum with that case.

The last time I thought about this, I came up with this list of things we want to allow in "open" enums:

	• Adding a new case.
	• Reordering existing cases is a "binary-compatible source-breaking change". In particular, if an enum is RawRepresentable, changing the raw representations of cases may break existing clients who use them for serialization.
	• Adding a raw type to an enum that does not have one.
	• Removing a non-public, non-versioned case (if we ever have such a thing).
	• Adding any other members.
	• Removing any non-public, non-versioned members.
	• Adding a new protocol conformance (with proper annotations).
	• Removing conformances to non-public protocols.

We're now questioning whether reordering should be allowed at all for implementation reasons, but other than that this list should still be accurate.

> 
> Vladimir. (P.S. Sorry for long reply)

Thanks for thinking about this in detail; better to get the problems out in the open now before I write up a formal proposal!

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170811/6a324919/attachment.html>