chrono icon indicating copy to clipboard operation
chrono copied to clipboard

Additional rkyv support by trying to derive the Archived type as Self where possible

Open yongqli opened this issue 3 years ago • 4 comments
trafficstars

The current support for rkyv in chrono isn't very useful, because rkyv generates a new type on each invocation of derive(Archive). This new type won't have any traits or methods implemented on it except Deserialize, so it can't be easily used in a zero-copy manner.

However, most chrono types are Copy, which means that rkyv can be configured to use Self for derive(Archive) instead of generating a new one. One downside is that this doesn't work if rkyv is configured to use a specific endianness.

Code can be generic to which specific type rkyv generated for the Archive impl through the use of rkyv::Archived<_>, so chrono can opportunistically generate a different type without breaking code that wants to support different endianness, which is also what rkyv currently does for primitives: https://docs.rs/rkyv/0.7.39/src/rkyv/impls/core/primitive.rs.html#107

yongqli avatar Aug 09 '22 05:08 yongqli

Looks like the test runner tried to enable incompatible features.

yongqli avatar Aug 09 '22 10:08 yongqli

Okay, that's a good reason this won't work: Cargo features must be additive and should not be mutually exclusive. Otherwise one library depending on Cargo could select one feature, another library selects the other, and the application wanting to use both libraries no longer works. So I don't think this can be merged as is.

djc avatar Aug 09 '22 10:08 djc

One possibility is to add a feature flag to enable attempting to derive using Self instead of the negative selection as it is now. I can also contact the rkyv author for recommendations and feedback.

yongqli avatar Aug 09 '22 12:08 yongqli

rust-decimal recently resolved a similar issue to this with serde by using #[serde(with = "")] attributes which are enabled by features, which enables multiple users of the same library to serialize differently and additively. Potentially this can be handled on the consumer side by using an equivalent attribute from rkyv?

esheppa avatar Aug 09 '22 13:08 esheppa

I agree it would be cool if Copy types would not even need a serialize/deserialize step when used with rkyv. And of course this breaks down when not everything uses the native endianness.

Closing for now. But if someone figures out a nice solution in https://github.com/rkyv/rkyv/issues/292 feel free to open a new PR.

pitdicker avatar Sep 19 '23 13:09 pitdicker