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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
