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.


> On Jan 12, 2018, at 4:16 PM, Jordan Rose <jordan_r...@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 <sw...@davedelong.com 
>> <mailto:sw...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to