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.

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.

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.


P.S. I'm not sure where you got "versioned" from. The attribute currently 
spelled '_versioned' in the Swift compiler is equivalent to what SE-0193 
 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.)

> On Jan 9, 2018, at 08:52, Jon Gilbert <swiftevolut...@jongilbert.com> wrote:
> 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”?
> 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.
> 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.
> Since versioning is really the main goal, why not use the same annotations 
> for versioning enums as are used for versioning everything else?
> @versioned
> enum MyError: Error {
> @available(OSX, deprecated:10.11, message: "this error case is going away in 
> 10.12")
> case BadThingHappened
> @available(forever)
> case ReallyBadThingHappened
> }
> etc.
> 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. 
> 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. 
> 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
> Jonathan

swift-evolution mailing list

Reply via email to