Add support for `uuid::Uuid`

[vnghia]

Close #33

[finnbear]

Thanks for the PR! Here are a few thoughts:

• I'm in favor of accepting this impl if uuid doesn't want to derive it :+1:
• The binary representation you chose differs from https://github.com/uuid-rs/uuid/pull/739. Theirs encodes a [u8; 16] whereas yours encodes a u128. There may be an alignment difference and, for that and other reasons, performance difference. I'll personally benchmark this before merging.
• I'd like to use the strategy I used in https://github.com/SoftbearStudios/bitcode/pull/30 to avoid writing custom code each time we need to encode one type in terms of another. That's not reviewed/merged yet so this will have to wait.

[vnghia]

Hi @finnbear, I use the new approach as you mentioned. Essentially just move ConvertFrom related code to a new mod and use that for encode/decode uuid. I let you decide which binary representation to go (u128 vs [u8;16]) but I think it is done on my side.

[finnbear]

Thanks for this! Regarding the encoding process, @caibear has recently started experimenting with using uuid's support for bytemuck to make it more efficient than what I suggested. I'll keep you updated :)

[retorted]

Any updates on this? Anything contributors can do to help?

UUID support would be really useful! :pray:

[finnbear]

Good to know multiple people want it. This increases the priority.

[caibear]

@finnbear if the representation can be switched to [u8; 16] to avoid bad u128 codegen and the ConvertFrom encoder can be removed (is already on main) I think this can be merged.

Edit: And also try to limit the scope of the changes to Cargo.toml and uuid.rs specificically

impl_convert!(uuid::Uuid, u128);

and

#[cfg(feature = "uuid")]
test!(uuid::Uuid::new_v4(), uuid::Uuid);