[swift-evolution] Enums and Source Compatibility

[Dave DeLong]

Hi Jordan,

One thing I’m still not clear on exhaustive vs non-exhaustive…

What will stop a developer from releasing an exhaustive enum in version 1 of their library, and then adding a new case in version 2?

With ABI stability and libraries getting updated independently of apps, this can be a major problem.

Dave


> On Sep 18, 2017, at 11:48 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I don't think unit tests help much here. In the case where an 'exhaustive' enum ought to be 'nonexhaustive', unit tests wouldn't help you catch the issue until you tried adding a new case. And in both cases, a unit test would only help if you tried to switch exhaustively over the enum, something you may not think to write (depending on what the enum is, of course).
> 
> In either direction, there's a potential error of omission, and if you've "omitted" the annotation from your library code I wouldn't assume you'd remember to check that specific thing in a unit test.
> 
> Jordan
> 
> 
>> On Sep 16, 2017, at 00:44, Goffredo Marocchi <panajev at gmail.com <mailto:panajev at gmail.com>> wrote:
>> 
>> Sorry for being naive, but aside from open (and the decision not to make it the default which again hurts the users of the library),  wouldn’t the playground library example be ok if the framework author had validated it with unit tests?
>> 
>> Sent from my iPhone
>> 
>> On 16 Sep 2017, at 01:07, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> Hi, Rex. I definitely agree that 'exhaustive' is the right model for a multi-module app; indeed, there's no real reason for a single project to do anything else. However, it is not always the right behavior for libraries that actually get distributed, whether as source or as binary. In this case we want to minimize the error of omission: in the app case, forgetting "exhaustive" is an annoyance that you notice and fix once across your code base, but in the library case forgetting the "default case" means putting out a source-breaking release, and for libraries that have binary compatibility constraints there's no recourse at all.
>>> 
>>> While most of the proposal deals with the experience we've had with the Apple SDKs (as written in Objective-C), we actually have run into this case in Swift already. The Swift Playgrounds app comes with a framework, PlaygroundSupport, that can be used from within a playground. It's important that when they upgrade the app, existing playgrounds don't break, since the end user may not have access to the entire code of the playground. (Remember that playgrounds are often authored by one developer or group, but then run and modified by someone else with a much lower skill level!) That means that PlaygroundSupport can't currently vend any enums that they expect playground authors to exhaustively switch over.
>>> 
>>> (And to make it even more specific—and appealing—one of the enums they were considering would be a representation of the Swift AST. This can obviously change from release to release, but previous switch statements should stay valid.)
>>> 
>>> Now, this is an example we know about, so we could certainly make it explicitly non-exhaustive. But in general we're in the same situation as 'open': if we want to be friendly to library authors, we need to make the default thing be the one that promises less, even if it means a bit of extra work in the "I-actually-own-everything" case.
>>> 
>>> Best,
>>> Jordan
>>> 
>>> 
>>>> On Sep 15, 2017, at 15:47, Rex Fenley <rex at remind101.com <mailto:rex at remind101.com>> wrote:
>>>> 
>>>> Hey Jordan,
>>>> 
>>>> Thank you for the time writing this up. I've been following along to the discussion somewhat closely and have kept silent because `exhaustive` was originally set to be the default for enums. However, that changed and so I'd like to voice my opinion, I frankly don't like this idea.
>>>> 
>>>> At remind we use algebraic data types religiously for managing state and data and rely on exhaustive pattern matching to guarantee we're handling all states in our code. We're splitting out our code across modules and having this guarantee has been a joy to work with.
>>>> 
>>>> The benefit of making nonexhaustive the default for Swift 5 across all multi-module code (besides C code) seems minimal to me. If a developer feels like they're unnecessarily managing enum cases, they can simply add a `default` case whenever they please. This is already the case and I'm curious if there's every been any complaints about this and what they would be. I'd prefer to be cautious and force exhaustive pattern matching in all possible cases and leave it up to the developer to choose not to.
>>>> 
>>>> Ideally in my mind, these keywords won't be necessary. All Swift enums will remain as they are, exhaustively pattern matched by default. Enums from C code will be explicitly nonexhaustive in all cases.
>>>> 
>>>> -- 
>>>> Rex Fenley  |  IOS DEVELOPER
>>>> 
>>>> 
>>>> Remind.com <https://www.remind.com/> |  BLOG <http://blog.remind.com/>  |  FOLLOW US <https://twitter.com/remindhq>  |  LIKE US <https://www.facebook.com/remindhq>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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