<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I assume you’re referring to this?<div class=""><h3 style="box-sizing: border-box; margin-top: 24px; margin-bottom: 16px; font-size: 1.25em; line-height: 1.25; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; background-color: rgb(255, 255, 255);" class="">Implicitly treat enums without binary compatibility concerns as <code style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: inherit; padding: 0.2em 0.4em; margin: 0px; background-color: rgba(27, 31, 35, 0.0470588); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">@frozen</code></h3><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; font-size: 16px; background-color: rgb(255, 255, 255);" class="">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.</p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; font-size: 16px; background-color: rgb(255, 255, 255);" class="">This question can be rephrased as "is adding a case to an enum a source-breaking change?" </p></div><div class=""><br class=""></div><div class="">I don’t follow on how this is a source-breaking change.</div><div class=""><br class=""></div><div class="">Let’s say I’m writing an app “A” that embeds a module “M”, which defines and enum “E”.</div><div class=""><br class=""></div><div class="">If E is frozen, the everything’s fine and all is well.</div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Dave</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 12, 2018, at 4:16 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I included that, but also I <i class="">again</i> 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.<div class=""><br class=""></div><div class="">Jordan<br class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 12, 2018, at 15:15, Dave DeLong <<a href="mailto:swift@davedelong.com" class="">swift@davedelong.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Unless I’m missing something, this is still missing the discussion on being able to treat all enums of internally-packaged libraries as frozen.<br class=""><br class="">IE, that frozen vs unfrozen is only an issue for enums that come from modules that are not packaged with your app.<br class=""><br class="">Dave<br class=""><br class=""><blockquote type="cite" class="">On Jan 12, 2018, at 4:08 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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.)<br class=""><br class="">I think the revised proposal is in good shape! (<a href="https://github.com/apple/swift-evolution/pull/777" class="">https://github.com/apple/swift-evolution/pull/777</a>) 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.<br class=""><br class="">Jordan<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>