uuid!("") literal macro

[awakecoding]

I am looking for a way to specify uuid literals in my code without having to do Uuid::parse_str("").unwrap(); at runtime. A good example for a different use case is the hex-literal crate (https://crates.io/crates/hex-literal) that makes is easy to specify hex literals with the hex!() macro. In this case, I would like to declare a UUID as a string like "cc58f58b-ca41-4678-b9f9-94ba4eeb9e1e" and have it checked for validity at compile-time to avoid the unwrap().

Maybe the best way would be to have the macro define a byte array to use Uuid::from_bytes() under the hood. Any thoughts?

[Dylan-DPC-zz]

Hi. Thanks for creating this issue.

A macro was always part of our plans but we never found time to implement and polish it. We decided to make it a separate repo. You can find it here: https://github.com/uuid-rs/uuid_macro. If you want to contribute to it, let us know and you are free to do so. Thanks.

GitHub

uuid-rs/uuid_macro

A compile time evaluated Uuid macro. Contribute to uuid-rs/uuid_macro development by creating an account on GitHub.

[awakecoding]

@Dylan-DPC thanks, I didn't know someone had begun working on it!

[kinggoesgaming]

Just to add on top of @Dylan-DPC's comment:

The eventual plan is to have the uuid! macro available directly with uuid crate (as a public dependency exposure) post 1.0 release of uuid

[Hawk777]

The uuid_macro crate has been yanked, but as far as I can tell no macro is available in this crate yet. Are there no macros at this point?

[kinggoesgaming]

Yes, it's currently yanked. It was only created for name reservation. We currently don't have plans to actually provide the macro until after 1.0 release.

[QnnOkabayashi]

Hello, I made compiled-uuid before I found this thread, and I'd love to formally implement it here if that's of interest.

[KodrAus]

Hey @QnnOkabayashi 👋 Nice! I've been wondering if it's possible to write a parser for UUIDs using const fn now that it's got quite a lot of support, but haven't had a chance to give it a try.

[QnnOkabayashi]

Hey @QnnOkabayashi 👋 Nice! I've been wondering if it's possible to write a parser for UUIDs using const fn now that it's got quite a lot of support, but haven't had a chance to give it a try.

const fns could be a solution, but const panics aren't stabilized yet so we lose all error information. On the other hand, proc macros allow us to have detailed errors, but only work at the token level and so they can only accept string literals.

[KodrAus]

@QnnOkabayashi That's true. I think it would be great to have a literal macro in the repository that we could look at re-exporting in uuid under a feature gate. We could convert this repository into a workspace and implement here if that's a direction you're interested in.

[QnnOkabayashi]

@KodrAus Yes, I think this would be great, and I'm happy to deprecate compiled_uuid in favor of a built-in solution. What would the process for converting to a workspace look like? I'm also not familiar with how to exactly create feature gates either.

Here's my current vision for the workspace organization:

• uuid gets turned into uuid-core, since it contains the main components.
• We introduce a uuid-proc-macro crate that depends on uuid-core for the parsing function.
• We introduce the overarching crate, uuid, that depends on uuid-core and uuid-proc-macro which just exports types and the macro, if the feature is enabled.

This way we have no cyclic dependencies. Thoughts?

[KodrAus]

Ah that’s a solid approach, but I think we might have to get creative to keep uuid itself dependency free by default (to avoid needing to create a uuid-core). What we could do is make the parser source shared between uuid and the macro crate. So instead of necessarily parsing a Uuid we can use the parser to get a shared [u8; 16]. That can then be tokenized in the Uuid::from_bytes we emit in the macro.

I’m happy to scaffold this all out for you if you wanted to fill in the blanks @QnnOkabayashi?