Should UUID conform to LosslessStringConvertible?

Development Core Libraries
1

I was a bit surprised see that UUID doesn't conform to LosslessStringConvertible, when I discovered that Vapor provides its own conformance:

Any reason for this omission? Should it be filed as private feedback, or are any of these Foundation issues tracked more publicly?

3 Likes
2

A couple of years ago, I tried this in apple/swift#28706 (tracked as rdar://problem/57847799).

Is it possible to add extension UUID: LosslessStringConvertible with narrower availability than the type — but without breaking source compatibility?

1 Like
3

I don't think so. I only brought this up because it'd be a useful conformance for Foundation to ship with, but I guess they're tracking it internally, so hopefully some day?

I've submitted a PR to Vapor removing this conformance since it seems like a problematic thing to include.

1 Like
4

The blocking issue at the time was that we couldn't add new protocol conformances with availability annotations. That's recently changed, so this looks like something we can now actually do. I'll check on the status of the bug. Thanks for pinging us!

13 Likes
5

Any updates on this? I do this massively in almost all my projects, and I always feel uncomfortable about it since I don't own either of the types.

6

It might be possible to add this to the new FoundationEssentials library.

(A conformance to UUID : Comparable was added in macOS 14 and iOS 17.)

Another issue is apple/swift-foundation#85. Should the uuidString, description, debugDescription, and Encodable representations be lowercased?

3 Likes