New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-9091] UUID does not follow RFC for string representation #3604
Comments
This seems important for interoperability. (Even though the other party is also at fault if they refuse to process uppercase UUIDs.) Changing UUID.uuidString may still be feasible, as doing that cannot currently cause binary compatibility issues. (Unlike NSUUID.) Source compatibility issues are possible, but limited, since the UUID initializer is case insensitive. Even if we rule out changing UUID.uuidString, perhaps it would make sense to at least change UUID's Encodable implementation to generate a lowercase encoding. |
Comment by Ben A (JIRA) Actually the issue we've been having isn't about deserializing uppercase or lowercase strings back into UUIDs. The issue is when multiple platforms save UUID strings of different cases in a shared web API backend. Let's say you have a web API backend that stores UUID strings as the primary key for objects that are created offline on native mobile client (e.g. Android and iOS devices). UUIDs that are the same, but sent to the web API backend from different clients, will not be equal when being compared for a primary key lookup, unless the web API backend is aware of the client-specific differences (Apple devices using uppercase and everyone else using lowercase) and normalizes on one case. Does that help clarify? |
It sounds super dangerous to change an existing API; if anyone is comparing UUIDs as strings and they happen to all be generated through NSUUID, their code is currently behaving as desired. I suspect Foundation will need to add a new API for this. |
Comment by Ben A (JIRA) I agree. Are there other types that have taken this kind of migration path? Ideally, there would be some way to opt UUID into using lowercase strings. |
Environment
macOS 10.13.6
Swift 4.2
Additional Detail from JIRA
md5: d7b6de109427ac7a4dfcc53d8d5cac3a
relates to:
Issue Description:
The RFC for
UUID
is explicit about the string representation being lowercase:But,
UUID
andNSUUID
both return uppercase strings foruuidString
, which is then used forUUID
's implementation ofEncodable
andCustomStringConvertible
. This makes cross platform issues around case-sensitive storage ofUUID
s very difficult to completely avoid. For this reason, we're likely going to stop using nativeUUID
in our app and use an internal clone that is the same except it always representsUUID
s as lowercase forString
representations.This has been an issue for us for some time, and we now have the time to figure out a more permanent solution to the various workarounds we have in place in our codebase (mostly just avoiding string interpolation with
UUID
and banning the use ofuuidString
). Now that Swift is open source and we can see the internals, the change feels pretty straightforward: change the one usage ofuuid_unparse
to instead beuuid_unparse_lower
. But, given the issues we're experience around case-sensitive storage of UUID strings, this feels like a significant breaking change. Additionally,NSUUID
's internals would also need to be updated.I'm happy to make an SE proposal for this, given that I understand the code change in Swift and can present it along with the proposal. That said, there's likely more to do and consider than just that, so I'm starting with this bug 🙂. It would be great to hear from knowledgeable members if this bug is enough, if I should make an SE proposal, or if I should do something beyond that.
Thanks for your consideration!
The text was updated successfully, but these errors were encountered: