[Review] SF-0041: UUID Version Support and Other Enhancements

[vanvoorden (Rick van Voorden)]

@available(FoundationPreview 6.4, *)
extension UUID {
    /// The variant of a UUID, as defined by RFC 9562 Section 4.1.
    public enum Variant: Sendable, Hashable {
        /// NCS backward compatibility (variant bits `0xx`).
        case ncs

        /// The variant specified by RFC 9562 (variant bits `10x`).
        case rfc9562

        /// Microsoft backward compatibility (variant bits `110`).
        case microsoft

        /// Reserved for future use (variant bits `111`).
        case reserved
    }

    /// The version of this UUID, derived from the version bits (bits 48–51) as defined by RFC 9562.
    public var version: Int { get set }

    /// The variant of this UUID, derived from the variant bits (bits 64–65) as defined by RFC 9562.
    public var variant: Variant { get }
}

I had a few questions here before about public enum types on ABI stable packages:

Avoiding `enum` across `public` API boundaries?

What happens if I need an API that returns a Planet from our solar system? Suppose I am a library maintainer and this API is public for consumers of my library. What data structure do I use to represent that Planet? Our first choice might be something like an enum. This is an example from TSPL: public enum Planet { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune } This works… but what happens when we add a new Planet? public enum Planet { ... case pluto } This is now…

I think an alternative might be a public struct Variant with static var properties exposing ncs etc. The actual enum type could then remain private. Any more pros and cons here that are worth discussing?