Shouldn't entomb and encode take a self rather than a &self?

TimelyDataflow / abomonation

A mortifying serialization library for Rust

MIT License

322 stars 30 forks source link

Shouldn't entomb and encode take a self rather than a &self? #18

Open HadrienG2 opened 5 years ago

HadrienG2 commented 5 years ago

In Rust terms, abomonation serialization is effectively a sophisticated move. Therefore, there is no technical reason why it shouldn't be possible to abomonate types which are movable but not clonable, such as Box<T> where T: !Clone.

However, the entomb operation, and its encode higher-level cousin take their input object by shared reference. This makes it impossible to correctly implement the Abomonation trait for non-copyable types, which needlessly restricts its applicability.

Please consider modifying this interface to take input objects by value instead.

frankmcsherry commented 5 years ago

I'm not sure I follow this. I don't think abomonation has any opinion on Clone, but it sounds like something about the interface makes life complicated for types which do not implement clone. Do you have an example at hand that demonstrates the difficulty implementing Abomonation?

HadrienG2 commented 5 years ago

Well, all the examples of movable-but-not-clonable types that I can come up with while trying to answer involve either...

Pointers, which are already taken care of by abomonation since it copies everything.
RAII tokens, which are not abomonation-compatible anyway because they rely on Drop, which abomonation does not run.

So this may actually not be as big of a problem as I thought while reviewing the API in the abstract.

But the abstract argument was that the current abomonation API is not safe for non-clonable types because it would allow things like serializing a MutexGuard pointing at a global variable, sending it to another thread, and then continuing to use it.