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?

enum MyError: Error {
@available(OSX, deprecated:10.11, message: "this error case is going away in 
case BadThingHappened

case ReallyBadThingHappened


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

swift-evolution mailing list

Reply via email to