<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=""><div class="">I'm not sure how this solves the problem. We need to know whether an enum may grow new cases or not, a concept that doesn't exist in Swift today. This is most interesting for enums in "libraries with binary compatibility concerns", but is also interesting for libraries that don't have such concerns, like source packages. Source packages don't use availability annotations.</div><div class=""><br class=""></div><div class="">We definitely need to be able to mark when enum cases were introduced, but the language already supports that, at least for libraries that are shipped with an Apple OS.</div><div class=""><br class=""></div><div class="">As for the name, I agree that 'exhaustive' isn't great. The best suggestion we got from the initial review was 'frozen', and that's what I'm putting in the next revision of the proposal.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. I'm not sure where you got "versioned" from. The attribute currently spelled '_versioned' in the Swift compiler is equivalent to what <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md" class="">SE-0193</a> calls 'abiPublic', at least in this revision. (I'm sorry to say I haven't caught up on all the discussion there, so I don't know if that's going to be spelled some other way.)</div><div class=""><br class=""></div><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 9, 2018, at 08:52, Jon Gilbert <<a href="mailto:swiftevolution@jongilbert.com" class="">swiftevolution@jongilbert.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Having reviewed much of the commentary on this proposal, I keep coming back to the same thought: why not use @versioned and @available keywords for this instead of some concept related to “exhaustive”?<br class=""><br class="">The issue here is not whether a given enum is “exhaustive” over the enumerated problem space; it’s whether the developer wants to alter the enum in the future without breaking ABI compatibility.<br class=""><br class="">If you call it “exhaustive” then it’s misleading, because all enums at a given moment in time can be switched over exhaustively. This will just confuse folks.<br class=""><br class="">Since versioning is really the main goal, why not use the same annotations for versioning enums as are used for versioning everything else?<br class=""><br class="">@versioned<br class="">enum MyError: Error {<br class="">@available(OSX, deprecated:10.11, message: "this error case is going away in 10.12")<br class="">case BadThingHappened<br class=""><br class="">@available(forever)<br class="">case ReallyBadThingHappened<br class="">}<br class=""><br class="">etc.<br class=""><br class="">That way you could have some cases get removed in the future as well as added, and you won’t confuse people by talking about “complete” or “exhaustive”, which are terms that are too closely coupled with the meaning and application of a given enum to which they refer. <br class=""><br class="">It would be best to use terms that just say what they mean. We are talking about versioning APIs to keep ABI stability? Use @versioned and @available like everywhere else. <br class=""><br class="">Or is there a compelling reason this cannot be done? I read much of the arguments here but didn’t see any mention of @versioned... maybe it’s iOS Mail app thinking I was looking for an email address that contains @versioned? ;D<br class=""><br class="">Jonathan<br class=""></div></div></blockquote></div><br class=""></body></html>