[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Jon Gilbert swiftevolution at jongilbert.com
Tue Jan 9 10:52:39 CST 2018


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


More information about the swift-evolution mailing list