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

Development Foundation
21

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).

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

3 Likes
22

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.

2 Likes
23

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

1 Like
24

So this corresponds to option 1 above:

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.

+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:

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

2 Likes