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

[Jon_Shier]

Sorry, I don't see an API design which explicitly allows invalid values to be reasonable. uuid.version == 123_456 will never be true, so an API that disallows it entirely is strictly superior to one that does. As mentioned earlier, this is also a general principle when using numeric types for non-numeric APIs, such as ID values, to avoid any API surface that doesn't make sense.

In this particular case, it prevents easy to make typos, like uuid.version == 9 (oops, meant == 8, now my code has a weird bug).

@Tony_Parker

This seems overly complicated versus just storing and representing it as an integer.

Correctness is almost always more complicated, but we pay that price for better experience. In many ways that's what Swift is all about.

[FlorianPircher]

Version being accessed as Int feels natural to me.

However, version also offering set access still feels strange to me. If someone wants to create a custom UUID value, they should be able to set the bits for the version as well as the rest of the UUID layout. Having API to change the version after creation could cause more issues than it solves.

[Jon_Shier]

My other question is, what the use case for setting the version of an existing UUID?

[tera]

@Tony_Parker

It's the lower 4 bits that are used.

So this corresponds to option 1 above:

@tera

1. Only the lower 4 (or, currently, 3) bits are used; all higher bits are silently ignored.

For example, all of the following will set the UUID version to 7 without producing any warning or error:

uuid.version = 39
uuid.version = -9
uuid.version = 31415926535

Not necessarily bad, but definitely something to be aware of.

@FlorianPircher

However, version also offering set access still feels strange to me.

@Jon_Shier

My other question is, what the use case for setting the version of an existing UUID?

+1, I have the same reaction and the same question.

---

Something else we briefly touched on earlier:

    public var lowercasedUUIDString: String { get }

I would suggest using a less cumbersome name instead, for example:

    public var string: String { get }

This would be more aligned with the recommendations from RFC 4122 and ISO/IEC 9834-8:2014:

6.5.4 Software generating the hexadecimal representation of a UUID shall not use upper case letters.

Potentially, uuidString could even be deprecated to encourage the lowercase representation more strongly.

[tinaliu (Tina L)]

Hi community,

The review for ran from 2026-05-20 through 2026-05-27. Thank you to everyone who participated. The workgroup would like to accept the proposal.

Summary

These topics came up during the review:

• lowercasedUUIDString naming: A suggestion was made to use string instead, on the grounds that lowercase hex is the canonical RFC form and the qualifier is therefore redundant. The workgroup does not have a strong opinion either way and defers to Tony.

• version4(using:) factory: There were discussions about whether this should be added alongside version7(using:) for symmetry. Tony's position is that it would duplicate the existing random(using:), and introducing a deprecation for naming reasons alone is not warranted. The workgroup defers to Tony on this too.

• var version type: Some preferred an enum for type safety and self-documentation, while others found x.version == 7 more natural. The workgroup felt this was the one point worth documenting explicitly, and Tony has since expanded Alternatives Considered to cover the tradeoff.

Decision: Accepted

The proposal has strong community support and the open design questions are addressed.

Thank you,
Tina, Review Manager