I added a blanket implementation for impl<T, C> Serializable for [T; C]. Together with the existing blanked implementation for Vec<T>, &Vec<T>, and &[T], it made these 3 implementations obsolete.

This deviates somewhat from how we serialize lists in that we try not to make assumptions data types used to serialize the number of elements. I think we can leave it up to the callers to figure out how exactly they want to serialize a given string.

I don't understand the problem. You don't want these implementations? You don't want to include the string length?

I guess the issue is with the use of as_bytes? You don't want to encode the data as utf8?

The biggest issue here is that the user can not implement this trait, because of the orphan rules. So here we either have to make the choice or not give an implementation to the user.

When the user is writing their own Serializable, they can also deviate from this by just not calling it.

I would prefer to remove these implementations as serializing strings without length is probably not a good idea, and serializing them with length is not consistent with the overall approach (e.g., different from how we serialize slices, vectors etc.).

I don't think this affects the usability too much as the user can serialize strings manually pretty easily - e.g.,:

let x = "hello world".to_string();

target.write_u64(x.len() as u64);
target.write_bytes(x.as_bytes());

On the deserialization front, I think we can improve the ergonomics by adding read_string() method to ByteReader interface. It could look something like:

fn read_string(&mut self, len: usize) -> Result<String, DeserializationError> {
    let data = source.read_vec(len)?;
    String::from_utf8(data).map_err(|err| DeserializationError::InvalidValue(format!("{err}")))
}

I would prefer to remove these implementations as serializing strings without length is probably not a good idea, and serializing them with length is not consistent with the overall approach (e.g., different from how we serialize slices, vectors etc.).

The question is, does it make sense to serialize slices and vectors without length too? And if this is done for consistency sake, why can't the String be serialized without the length too?

I don't think this affects the usability too much as the user can serialize strings manually pretty easily - e.g.,:

Your call

On the deserialization front, I think we can improve the ergonomics by adding read_string() method to ByteReader interface. It could look something like:

This can be done in another PR.

Removed the default implementation

Similar comment to one of the previous comments re strings: I'd rather not make opinionated choices about which data type to use for serializing string lengths.

It is a bit unfortunate that we have to allocate a vector here to deserialize the data - but I wonder if the compiler is smart enough to figure out that this is not needed.