Add support for rkyv and bytecheck

[djkoloski]

Is your feature request related to a problem? Please describe.
A couple rkyv users are using uuid and want to be able to serialize, access, and deserialize Uuids.

Describe the solution you'd like
An rkyv feature that adds rkyv support for Uuid and a bytecheck feature that adds bytecheck support for Uuid.

Is it blocking?
Not blocking any releases, but there is a tracking issue in rkyv.

Describe alternatives you've considered
Providing implementations for Uuid in rkyv can be done behind a uuid feature. This will get users working again, but it goes against the precedent set by serde that impls live in the crate the serializable type is defined. It also prevents situations where rkyv/bytecheck updates their impls and users cannot select a version of the library that satisfies all of their dependency versions.

A wrapper type can be used to wrap the Uuid type and provide rkyv and bytecheck support, but would require re-implementing all of the functionality (public methods and trait impls).

Additional context
I have an implementation ready to go in a fork commit so that anyone interested can see what the implementation would look like. These implementations should be relatively resilient to change.

You can learn more about rkyv from the book and the docs if you're not familiar with it.

Bytecheck is pretty straightforward with docs available.

Other
rkyv tracking issue

Thanks for the work you do! ❤

[djkoloski]

Bumping this, I can file a pull request from that repo instead if that would be preferable.

[KodrAus]

Hi @djkoloski! 👋

Sorry for the late response here. Unfortunately we can't really add public trait implementations for unstable libraries, because those would require a major version bump in uuid to keep up with. It looks like you've since gone and added internal support in rkyv for uuid. Ideally we'd have some kind of rkyv1 feature here in uuid when it's all stable so you won't need to pull in every datatype library under the sun in rkyv.

[djkoloski]

That sounds like a good plan, I think that's a sustainable approach for now. I'll circle back around to this issue when rkyv reaches a stable state.

[KodrAus]

I'm just coming through some triage. It's a bit regrettable that we have to compromise supporting new libraries with maintaining stability. You kind of need libraries in the ecosystem to support your traits before you necessarily have critical mass that makes them stable.

I'd be open to looking at ways to make it possible to support rkyv as it develops if we can come up with a scheme that lets users opt-in to following rkyv's own release train. Something other libraries have done in the past is adding an opt-in environment variable for allowing unstable features. That means it's something apps could reasonably add to their builds but other libraries couldn't.

I'll go ahead and close this one for now though because we haven't got anything actionable specific for rkyv yet, but would be keen to figure this out!

[KodrAus]

This will be less friendly for end-users, but we do now have a way to introduce unstable features that we can bump in minor versions of uuid before promoting them to a stable feature. The first is implemented in #538

The caveat is that users need to explicitly set a RUSTFLAGS cfg in order to use them.

[djkoloski]

Thanks, I'll take a look at this. I appreciate the effort you're putting into solving this issue!