[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Dave DeLong]

I assume you’re referring to this?
Implicitly treat enums without binary compatibility concerns as @frozen

Several people questioned whether it was necessary to make this distinction for libraries without binary compatibility concerns, i.e. those that are shipped with their client apps. While there may be a need to do something to handle enums shipped with Apple's OS SDKs, it's arguable whether this is worth it for "source libraries", such as SwiftPM packages.

This question can be rephrased as "is adding a case to an enum a source-breaking change?" 


I don’t follow on how this is a source-breaking change.

Let’s say I’m writing an app “A” that embeds a module “M”, which defines and enum “E”.

If E is frozen, the everything’s fine and all is well.
If E is *not* frozen, then the compiler is going to force me to put in an “unknown case”, because it has falsely concluded that E may change out from underneath my app.

The will be a mistake on the compiler’s part. I do not need to include the “unknown case” handler while enumerating on E, because there is no possibility of ever getting an unknown enum value from M, because it is statically copied in to my app and will never change.

Dave

> On Jan 12, 2018, at 4:16 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> I included that, but also I again don't think that's the correct design. There's a case where that's useful, but that shouldn't be the default, and I don't think it's important enough to do in Swift 5.
> 
> Jordan
> 
> 
>> On Jan 12, 2018, at 15:15, Dave DeLong <swift at davedelong.com <mailto:swift at davedelong.com>> wrote:
>> 
>> Unless I’m missing something, this is still missing the discussion on being able to treat all enums of internally-packaged libraries as frozen.
>> 
>> IE, that frozen vs unfrozen is only an issue for enums that come from modules that are not packaged with your app.
>> 
>> Dave
>> 
>>> On Jan 12, 2018, at 4:08 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's point very specifically: if the compiler emits an error, we should go with `case #unknown` instead. (I'm very strongly in the "warning" camp, though.)
>>> 
>>> I think the revised proposal is in good shape! (https://github.com/apple/swift-evolution/pull/777 <https://github.com/apple/swift-evolution/pull/777>) I think I've addressed everyone's feedback either in the proposal or on-list, if not necessarily convinced them. If there are no other major comments I'll let Ted know that it's ready to re-run on Monday.
>>> 
>>> Jordan
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto: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/20180112/e35f2dbf/attachment.html>