[swift-evolution] Enums and Source Compatibility

[Dave DeLong]

I also realize that this may be an impractical approach to solving this problem, because it would require teaching the analyzer about built products, with knowledge of what’s going to be copied, etc etc.

So, the alternative view to this would be:

- any enum that you are compiling is exhaustive
- everything else is non-exhaustive

Dave

> On Sep 28, 2017, at 4:18 PM, Dave DeLong via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I don’t think this use-case should be overlooked, especially as we approach the stable ABI.
> 
> If a library can change out from underneath you (because you’re not embedding it yourself) then it is inherently unsafe to assume that any enum in that library is exhaustive. The developer may think that it is for version 1, but the development of version 2 may reveal cases that were not originally considered. Apple, which has just about as much experience as anyone in the world with shipping frameworks, has a strong commitment to binary compatibility, but even they get it wrong sometimes.
> 
> IMO, the proper way to deal with “exhaustive” enums vs not is:
> 
> - any enum in any framework you ship is exhaustive. (Rationale: since you’re embedding it with your product, you have explicit control over handling all its cases)
> 
> - any enum in any framework you link is non-exhaustive. (Rationale: since the framework is not part of your product, it could change without you knowing, which means you must handle unexpected values via a default case)
> 
> Dave
> 
>> On Sep 21, 2017, at 12:48 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> 
>>> On Sep 20, 2017, at 16:15, Dave DeLong <swift at davedelong.com <mailto:swift at davedelong.com>> wrote:
>>> 
>>> 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.
>> 
>> We have some ideas to deal with this, though nothing promised yet:
>> 
>> - A checker that can compare APIs across library versions, using swiftmodule files or similar.
>> - Encoding the layout of a type in a symbol name. We could have clients link against this symbol so that they’d fail to launch if it changes, or just check the list of exported symbols to make sure it didn’t change.
>> 
>> The feature’s useful even if we have to do it by hand for now, but it’s a good question to ask. I’ll mention this in the proposal under “Future directions”.
>> 
>> Jordan
> 
> _______________________________________________
> 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/20170928/f70aeeaa/attachment.html>